Re: Further pg_upgrade analysis for many tables - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Further pg_upgrade analysis for many tables
Date
Msg-id CAMkU=1zcCrJjCSNLK7kr=atombXzzMU-s3H7tMqodz4i40+DjQ@mail.gmail.com
Whole thread Raw
In response to Re: Further pg_upgrade analysis for many tables  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Sunday, January 20, 2013, Stephen Frost wrote:
* Jeff Janes (jeff.janes@gmail.com) 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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: gistchoose vs. bloat
Next
From: Pavan Deolasee
Date:
Subject: Re: Removing PD_ALL_VISIBLE