> "MichaelDBA" == MichaelDBA writes:
MichaelDBA> Yep, you're right, Andrew, adding a couple rows made it do
MichaelDBA> the index only scan. I reckon I got misled by turning off
MichaelDBA> sequential scans, thinking that actual rows were not
MichaelDBA> important anymore. Overly simpl
> "MichaelDBA" == MichaelDBA writes:
MichaelDBA> Nope, vacuumed it and still got the bitmap index scans.
Let's see your explains. Here's mine:
# set enable_seqscan=false; -- because I only have a few rows
SET
# insert into friend values (1,2),(2,5);
INSERT 0 2
# vacuum analyze friend;
VA
> "MichaelDBA" == MichaelDBA writes:
MichaelDBA> BTW, to Andrew, the UNION ALL alternative still results in
MichaelDBA> bitmap index scans from my testing.
You probably forgot to vacuum the table.
--
Andrew (irc:RhodiumToad)
> "Ivan" == Ivan Voras writes:
Ivan> Hello,
Ivan> There's a "users" table with the following structure:
Ivan> CREATE TABLE "user" (
Ivan> id SERIAL PRIMARY KEY,
Ivan> -- other fields
Ivan> );
Ivan> and there's a "friends" table with the following structure:
Ivan> CREATE TABLE fr
> "Ogden" == Ogden Brash writes:
Ogden> I did the restore as a data only restore so that it would not
Ogden> try to recreate any tables.
Doing data-only restores is almost always a mistake.
pg_dump/pg_restore are very careful to create things in an order that
allows the data part of the r
> "Ogden" == Ogden Brash writes:
Ogden> I have a question about the files in
Ogden> .../data/postgresql/11/main/base, specifically in relation to
Ogden> very large tables and how they are written.
Ogden> I have been attempting to restore a relatively large database
Ogden> with pg_restor
> "tank" == tank zhang <6220...@qq.com> writes:
tank> smtoc| character varying(50) | | |
tank> Sort Key: smtoc
What is the output of SHOW lc_collate;
One of the most common reasons for slow sorting is that you're sorting a
text/varchar field in
> "Gunther" == Gunther writes:
Gunther> foo=# CREATE UNIQUE INDEX Test_pk0 ON Test(id) WHERE mod(id,2) = 0;
Gunther> CREATE INDEX
Gunther> foo=# EXPLAIN SELECT * FROM Test WHERE id = '8934';
Gunther> QUERY PLAN
Gunther>
> "Abi" == Abi Noda writes:
Abi> However, when I index the closed column, a bitmap scan is used
Abi> instead of an index scan, with slightly slower performance. Why
Abi> isn't an index scan being used, given that the exact same number
Abi> of rows are at play as in my query on the state c
> "Jung" == Jung, Jinho writes:
Jung> select distinct
Jung> ref_0.i_im_id as c0,
Jung> ref_1.ol_dist_info as c1
Jung> from
Jung> public.item as ref_0 right join
Jung> public.order_line as ref_1
Jung> on (ref_0.i_id = 5)
Jung> - Commit: 84f9a35 (Improve e
> "Bob" == Bob Jolliffe writes:
Bob> Excuse me if this is a silly question. I am trying to fiddle with
Bob> shared_buffers setting on postgresql 10.6 on ubuntu 18.04 server.
Bob> I have this at bottom of my config file:
Bob> shared_buffers = 1GB
Bob> Yet when I check the setting from p
> "Vladimir" == Vladimir Ryabtsev writes:
>> The workaround is to do it like this instead:
Vladimir> Strange, I tried to do like this, but the first thing came
Vladimir> into my mind was array_agg() not array():
Vladimir> delete from log
Vladimir> where ctid = any(
Vladimir> selec
> "Vladimir" == Vladimir Ryabtsev writes:
Vladimir> I can't believe it.
Vladimir> I see some recommendations in Internet to do like this
well, 90% of what you read on the Internet is wrong.
Vladimir> Did it really work in 2011? Are you saying they broke it?
Vladimir> It's a shame...
Th
> "Mariel" == Mariel Cherkassky writes:
Mariel> Hi,
Mariel> Does the work mem is used when I do sorts or hash operations on
Mariel> temp tables ? Or the temp_buffer that is allocated at the
Mariel> beginning of the session is used for it ?
work_mem is used for sorts and hashes regardless
14 matches
Mail list logo
