Re: Further pg_upgrade analysis for many tables

On Wed, Nov 14, 2012 at 11:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
>> On Thu, Nov 8, 2012 at 9:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> There are at least three ways we could whack that mole: ...
>>>
>>> * Keep a separate list (or data structure of your choice) so that
>>> relcache entries created in the current xact could be found directly
>>> rather than having to scan the whole relcache.  That'd add complexity
>>> though, and could perhaps be a net loss for cases where the relcache
>>> isn't so bloated.
>
>> Maybe a static list that can overflow, like the ResourceOwner/Lock
>> table one recently added.  The overhead of that should be very low.
>
>> Are the three places where "need_eoxact_work = true;" the only places
>> where things need to be added to the new structure?
>
> Yeah.  The problem is not so much the number of places that do that,
> as that places that flush entries from the relcache would need to know
> to remove them from the separate list, else you'd have dangling
> pointers.

If the list is of hash-tags rather than pointers, all we would have to
do is ignore entries that are not still in the hash table, right?


On a related thought, is a shame that "create temp table on commit
drop" sets "need_eoxact_work", because by the time we get to
AtEOXact_RelationCache upon commit, the entry is already gone and so
there is actual work to do (unless a non-temp  table was also
created).  But on abort, the entry is still there.  I don't know if
there is an opportunity for optimization there for people who use temp
tables a lot.  If we go with a caching list, that would render it moot
unless they use so many as to routinely overflow the cache.

Cheers,

Jeff