Re: Further pg_upgrade analysis for many tables

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. It's certainly not impossible, I was just unsure how much
of a pain in the rear it might be.

> The next quadratic behavior is in init_sequence.

Yeah, that's another place that is using a linear list that perhaps
should be a hashtable. OTOH, probably most sessions don't touch enough
different sequences for that to be a win.

regards, tom lane