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. +