Greg Stark <gsst...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
