Re: 9.3 release notes suggestions

On Sat, May  4, 2013 at 07:59:40PM +0200, Tomas Vondra wrote:
> On 24.4.2013 05:41, Bruce Momjian wrote:
> > Thanks for the many suggestions on improving the 9.3 release notes.
> > There were many ideas I would have never thought of.  Please keep the
> > suggestions coming.
> 
> Lovely, good job Bruce!
> 
> I've checked descriptions of changes I've been working on, and I think
> this one is incorrect:
> 
>    Improve performance for transactions creating, rebuilding, or
>    dropping many relations (Jeff Janes, Tomas Vondra)
> 
> I assume this is commit 279628a0a7cf582f7dfb68e25b7b76183dd8ff2f. That
> however improves DROP only - it has nothing to do with creating or
> rebuilding relations. Or is it a condensed description of changes made
> by some other patches?

Yes, it is a composite of your patch and one by Jeff Janes:
    Fix an O(N^2) performance issue for sessions modifying many relations.    AtEOXact_RelationCache() scanned the
entirerelation cache at the end of    any transaction that created a new relation or assigned a new relfilenode.
Thus,clients such as pg_restore had an O(N^2) performance problem that    would start to be noticeable after creating
10000or so tables.  Since    typically only a small number of relcache entries need any cleanup, we    can fix this by
keepinga small list of their OIDs and doing hash_searches    for them.  We fall back to the full-table scan if the list
overflows.   Ideally, the maximum list length would be set at the point where N    hash_searches would cost just less
thanthe full-table scan.  Some quick    experimentation says that point might be around 50-100; I (tgl)
conservativelyset MAX_EOXACT_LIST = 32.  For the case that we're worried    about here, which is short single-statement
transactions,it's unlikely    there would ever be more than about a dozen list entries anyway; so it's    probably not
worthbeing too tense about the value.    We could avoid the hash_searches by instead keeping the target relcache
entrieslinked into a list, but that would be noticeably more complicated    and bug-prone because of the need to
maintainsuch a list in the face of    relcache entry drops.  Since a relcache entry can only need such cleanup    after
asomewhat-heavyweight filesystem operation, trying to save a    hash_search per cleanup doesn't seem very useful anyway
---it's the scan    over all the not-needing-cleanup entries that we wish to avoid here.    Jeff Janes, reviewed and
tweakeda bit by Tom Lane(Tom Lane)[d5b31cc32] 2013-01-20 13:45:10 -0500
 

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +