Tom Lane wrote:
> I wrote:
> > 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.
>
> I looked into that a bit more and decided that it'd be a ticklish
> change: the coupling between relcache and smgr cache is pretty tight,
> and there just isn't any provision for having an smgr cache entry live
> longer than its owning relcache entry. Even if we could fix it to
> work reliably, this approach does nothing for the case where a backend
> actually exits after filling just part of a new page, as noted by
> Takahiro-san.
>
> The next most promising fix is to have RelationGetBufferForTuple tell
> the FSM about the new page immediately on creation. I made a draft
> patch for that (attached). It fixes Michael's scenario nicely ---
> all pages get filled completely --- and a simple test with pgbench
> didn't reveal any obvious change in performance. However there is
> clear *potential* for performance loss, due to both the extra FSM
> access and the potential for increased contention because of multiple
> backends piling into the same new page. So it would be good to do
> some real performance testing on insert-heavy scenarios before we
> consider applying this. Any volunteers?
I have added this TODO:
Allow concurrent inserts to use recently created pages rather thancreating new ones *
http://archives.postgresql.org/pgsql-hackers/2010-05/msg00853.php
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +