On Wed, Nov 14, 2012 at 11:49 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Jeff Janes <jeff.ja...@gmail.com> writes: >> On Thu, Nov 8, 2012 at 9:50 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
