From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Renner <michael(dot)renner(at)amd(dot)co(dot)at>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Unexpected page allocation behavior on insert-only tables |
Date: | 2010-05-31 05:23:37 |
Message-ID: | 26120.1275283417@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-05-31 08:33:16 | Re: PG 9.0 release timetable |
Previous Message | Greg Stark | 2010-05-31 05:09:49 | Re: Unexpected page allocation behavior on insert-only tables |