Re: Unexpected page allocation behavior on insert-only tables

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. +