Re: Further pg_upgrade analysis for many tables

On Thu, Nov 15, 2012 at 07:05:00PM -0800, Jeff Janes wrote:
> 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.

I added the attached C comment last year to mention why temp tables are
not as isolated as we think, and can't be optimized as much as you would
think.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +