On Thu, Nov 15, 2012 at 07:05:00PM -0800, Jeff Janes wrote:
> 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.
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 <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
commit f458c90bff45ecae91fb55ef2b938af37d977af3
Author: Bruce Momjian <br...@momjian.us>
Date: Mon Sep 5 22:08:14 2011 -0400
Add C comment about why we send cache invalidation messages for
session-local objects.
diff --git a/src/backend/utils/cache/inval.c b/src/backend/utils/cache/inval.c
new file mode 100644
index 337fe64..98dc3ad
*** a/src/backend/utils/cache/inval.c
--- b/src/backend/utils/cache/inval.c
*************** ProcessCommittedInvalidationMessages(Sha
*** 812,817 ****
--- 812,821 ----
* about CurrentCmdInvalidMsgs too, since those changes haven't touched
* the caches yet.
*
+ * We still send invalidation messages for session-local objects to other
+ * backends because, while other backends cannot see any tuples, they can
+ * drop tables that are session-local to another session.
+ *
* In any case, reset the various lists to empty. We need not physically
* free memory here, since TopTransactionContext is about to be emptied
* anyway.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
