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 entire relation 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 10000 or so tables.
Since
typically only a small number of relcache entries need any cleanup,
we
can fix this by keeping a 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 than the full-table scan. Some
quick
experimentation says that point might be around 50-100; I (tgl)
conservatively set 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 worth being too tense about the value.
We could avoid the hash_searches by instead keeping the target
relcache
entries linked into a list, but that would be noticeably more
complicated
and bug-prone because of the need to maintain such a list in the
face of
relcache entry drops. Since a relcache entry can only need such
cleanup
after a somewhat-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 tweaked a bit by Tom Lane
(Tom Lane)
[d5b31cc32] 2013-01-20 13:45:10 -0500
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
