On Oct 3, 2012, at 11:50 AM, Tom Lane wrote: > Ben Chobot <bench@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
