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? > > Note: patch is against HEAD but should work in 8.4, if you reverse out > the use of the rd_targblock access macros.
Is this something we want to address or should I just add it to the TODO? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
