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