Re: Unexpected page allocation behavior on insert-only tables

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Unexpected page allocation behavior on insert-only tables
Дата
Msg-id 26120.1275283417@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Unexpected page allocation behavior on insert-only tables  (Greg Stark <gsstark@mit.edu>)
Ответы Re: Unexpected page allocation behavior on insert-only tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> This is an analyze-only scan? Why does analyze need to issue a
> relcache flush?

Directly: to cause other backends to pick up the updated pg_class row
(with new relpages/reltuples data).

Indirectly: to cause cached plans for the rel to be invalidated,
so that they can get replanned with updated pg_statistic entries.

So we can't just not have a relcache flush here.  However, we
might be able to decouple targblock reset from the rest of it.
In particular, now that there's a distinction between smgr flush
and relcache flush, maybe we could associate targblock reset with
smgr flush (only) and arrange to not flush the smgr level during
ANALYZE --- basically, smgr flush would only be needed when truncating
or reassigning the relfilenode.  I think this might work out nicely but
haven't chased the details.
        regards, tom lane


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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Unexpected page allocation behavior on insert-only tables
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: PG 9.0 release timetable