Re: CREATE INDEX speeds up query on 31 row table ...

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: CREATE INDEX speeds up query on 31 row table ...
Дата
Msg-id 87k6ub4nka.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на CREATE INDEX speeds up query on 31 row table ...  ("Marc G. Fournier" <scrappy@postgresql.org>)
Ответы Re: CREATE INDEX speeds up query on 31 row table ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: CREATE INDEX speeds up query on 31 row table ...  ("Matthew T. O'Connor" <matthew@zeut.net>)
Список pgsql-hackers
"Marc G. Fournier" <scrappy@postgresql.org> writes:

> Its a *very* busy table ... and running on a 7.4.0 database ...

I wonder how many tuples are really in this table. Almost all of the 190ms is
spent in the two sequential scans of it. Which is an awful lot of time for a
32 tuple table. 

You say it's "*very* busy" is it possible there are hundreds or thousands of
tuples in there that are uncommitted or committed after this query starts?

Alternatively, try a "vacuum full". If that helps then autovacuum is having
trouble keeping up with the rate of creation of dead tuples. You would have to
increase the FSM parameters.

Presumably autovacuum has warnings when it detects that scenario?

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: SIGABRT on 7.4.5
Следующее
От: Gaetano Mendola
Дата:
Сообщение: Re: FlushRelationBuffers error