On Oct 3, 2012, at 11:50 AM, Tom Lane wrote: > Ben Chobot <be...@silentmedia.com> writes: >> 4. What might cause autovacuum analyze to make an index perform worse >> immediately, when a manual vacuum analyze does not have the same affect? And >> I'm not talking about changing things so the planner doesn't use the index, >> but rather, having the index actually take longer. > > Dunno about the replication angle, but would this have been a GIN index? > I'm wondering about possible interference with flushing of its > pending-insert queue (the FASTUPDATE stuff).
Nope, btree: create index get_delayed_jobs_index on delayed_jobs (priority, run_at) tablespace data1 where locked_at is null and queue='queue' and next_in_strand=true; There are half a dozen other indices on this table too (that weren't applicable to the long query) but they're all btrees. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
