Re: Further pg_upgrade analysis for many tables

Jeff Janes <jeff.janes@gmail.com>

From: Jeff Janes <jeff.janes@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Simon Riggs <simon@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <bruce@momjian.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Magnus Hagander <magnus@hagander.net>
Date: 2013-01-21T05:51:11Z
Lists: pgsql-hackers
On Sunday, January 20, 2013, Stephen Frost wrote:

> * Jeff Janes (jeff.janes@gmail.com <javascript:;>) wrote:
>


> > By making the list over-flowable, we fix a demonstrated pathological
> > workload (restore of huge schemas); we impose no detectable penalty to
> > normal workloads; and we fail to improve, but also fail to make worse, a
> > hypothetical pathological workload.  All at the expense of a few bytes
> per
> > backend.
> [...]
> > > Why does the list not grow as needed?
> >
> > It would increase the code complexity for no concretely-known benefit.
>
> I'm curious if this is going to help with rollback's of transactions
> which created lots of tables..?  We've certainly seen that take much
> longer than we'd like, although I've generally attributed it to doing
> all of the unlink'ing and truncating of files.
>

If you are using large shared_buffers, then you will probably get more
benefit from a different recent commit:

279628a  Accelerate end-of-transaction dropping of relations.

Cheers,

Jeff