Re: Further pg_upgrade analysis for many tables

On Wed, Nov 14, 2012 at 11:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
>> On Thu, Nov 8, 2012 at 9:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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