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
|
Список | 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 по дате отправления: