Re: Unexpected page allocation behavior on insert-only tables

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, 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: 2011-02-17 03:22:25
Message-ID: 201102170322.p1H3MPE07664@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 than
creating new ones

* http://archives.postgresql.org/pgsql-hackers/2010-05/msg00853.php

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2011-02-17 03:27:39 Re: Debian readline/libedit breakage
Previous Message Bruce Momjian 2011-02-17 03:16:15 Re: Debian readline/libedit breakage