Shared invalidation cache messages for temporary tables

Looking at the code, it seems we create shared invalidation messages for
temporary table activity? Is this true? Should we be avoiding it?

I tested this by reviewing the code and checking calls to
CacheInvalidateHeapTuple(), which happens for temporary table
creation/destruction.

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

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

On Fri, 2011-03-11 at 20:44 -0500, Bruce Momjian wrote:
> Looking at the code, it seems we create shared invalidation messages for
> temporary table activity? Is this true? Should we be avoiding it?
>
> I tested this by reviewing the code and checking calls to
> CacheInvalidateHeapTuple(), which happens for temporary table
> creation/destruction.

Yes, that gets called.

But in PrepareForTupleInvalidation() we ignore everything apart from
system relations, as the first check.

--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services

Simon Riggs wrote:
> On Fri, 2011-03-11 at 20:44 -0500, Bruce Momjian wrote:
> > Looking at the code, it seems we create shared invalidation messages for
> > temporary table activity? Is this true? Should we be avoiding it?
> >
> > I tested this by reviewing the code and checking calls to
> > CacheInvalidateHeapTuple(), which happens for temporary table
> > creation/destruction.
>
> Yes, that gets called.
>
> But in PrepareForTupleInvalidation() we ignore everything apart from
> system relations, as the first check.

OK, so this is no problem? There is no optimization needed here?
Thanks.

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

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

On Mon, Mar 14, 2011 at 8:42 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Simon Riggs wrote:
>> On Fri, 2011-03-11 at 20:44 -0500, Bruce Momjian wrote:
>> > Looking at the code, it seems we create shared invalidation messages for
>> > temporary table activity?  Is this true?  Should we be avoiding it?
>> >
>> > I tested this by reviewing the code and checking calls to
>> > CacheInvalidateHeapTuple(), which happens for temporary table
>> > creation/destruction.
>>
>> Yes, that gets called.
>>
>> But in PrepareForTupleInvalidation() we ignore everything apart from
>> system relations, as the first check.
>
> OK, so this is no problem?  There is no optimization needed here?
> Thanks.

Since your original email is fairly unclear about what you think the
problem is, it's a bit hard to speculate here, but like Simon, I don't
see any obvious problem here. Maybe you're asking not so much about
inserts, updates, or deletes into temporary tables but about creating
and making modifications to them, which will generate catcache and
relcache flushes when the pg_class/pg_attribute entries are updated.
But I don't think those invalidation messages can be optimized away,
since other backends can access temporary tables of other sessions in
limited ways - for example, they can drop them.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas wrote:
> On Mon, Mar 14, 2011 at 8:42 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Simon Riggs wrote:
> >> On Fri, 2011-03-11 at 20:44 -0500, Bruce Momjian wrote:
> >> > Looking at the code, it seems we create shared invalidation messages for
> >> > temporary table activity? ?Is this true? ?Should we be avoiding it?
> >> >
> >> > I tested this by reviewing the code and checking calls to
> >> > CacheInvalidateHeapTuple(), which happens for temporary table
> >> > creation/destruction.
> >>
> >> Yes, that gets called.
> >>
> >> But in PrepareForTupleInvalidation() we ignore everything apart from
> >> system relations, as the first check.
> >
> > OK, so this is no problem? ?There is no optimization needed here?
> > Thanks.
>
> Since your original email is fairly unclear about what you think the
> problem is, it's a bit hard to speculate here, but like Simon, I don't
> see any obvious problem here. Maybe you're asking not so much about
> inserts, updates, or deletes into temporary tables but about creating
> and making modifications to them, which will generate catcache and
> relcache flushes when the pg_class/pg_attribute entries are updated.
> But I don't think those invalidation messages can be optimized away,
> since other backends can access temporary tables of other sessions in
> limited ways - for example, they can drop them.

Sorry, yes that was my point --- should we be doing as much cache
invalidation traffic for temporary tables as we are doing? I think you
are saying we are fine and there are no optimizations possible.

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

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

On Mon, Mar 14, 2011 at 10:21 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> Since your original email is fairly unclear about what you think the
>> problem is, it's a bit hard to speculate here, but like Simon, I don't
>> see any obvious problem here.  Maybe you're asking not so much about
>> inserts, updates, or deletes into temporary tables but about creating
>> and making modifications to them, which will generate catcache and
>> relcache flushes when the pg_class/pg_attribute entries are updated.
>> But I don't think those invalidation messages can be optimized away,
>> since other backends can access temporary tables of other sessions in
>> limited ways - for example, they can drop them.
>
> Sorry, yes that was my point --- should we be doing as much cache
> invalidation traffic for temporary tables as we are doing?  I think you
> are saying we are fine and there are no optimizations possible.

Yeah, I think so. I mean, if you have a concrete example of this
causing a problem, then we can look into it, but my intuition is that
it's OK. Programmers intuition are notoriously wrong, of course, so
we're all just shooting in the dark until we have something to
measure.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mar 14, 2011, at 9:29 AM, Robert Haas wrote:

> On Mon, Mar 14, 2011 at 10:21 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>> Since your original email is fairly unclear about what you think the
>>> problem is, it's a bit hard to speculate here, but like Simon, I don't
>>> see any obvious problem here. Maybe you're asking not so much about
>>> inserts, updates, or deletes into temporary tables but about creating
>>> and making modifications to them, which will generate catcache and
>>> relcache flushes when the pg_class/pg_attribute entries are updated.
>>> But I don't think those invalidation messages can be optimized away,
>>> since other backends can access temporary tables of other sessions in
>>> limited ways - for example, they can drop them.
>>
>> Sorry, yes that was my point --- should we be doing as much cache
>> invalidation traffic for temporary tables as we are doing? I think you
>> are saying we are fine and there are no optimizations possible.
>
> Yeah, I think so. I mean, if you have a concrete example of this
> causing a problem, then we can look into it, but my intuition is that
> it's OK. Programmers intuition are notoriously wrong, of course, so
> we're all just shooting in the dark until we have something to
> measure.

Sounds like there should be a comment somewhere in the code that explains why we actually need those messages...
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

Jim Nasby wrote:
> On Mar 14, 2011, at 9:29 AM, Robert Haas wrote:
>
> > On Mon, Mar 14, 2011 at 10:21 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >>> Since your original email is fairly unclear about what you think the
> >>> problem is, it's a bit hard to speculate here, but like Simon, I don't
> >>> see any obvious problem here. Maybe you're asking not so much about
> >>> inserts, updates, or deletes into temporary tables but about creating
> >>> and making modifications to them, which will generate catcache and
> >>> relcache flushes when the pg_class/pg_attribute entries are updated.
> >>> But I don't think those invalidation messages can be optimized away,
> >>> since other backends can access temporary tables of other sessions in
> >>> limited ways - for example, they can drop them.
> >>
> >> Sorry, yes that was my point --- should we be doing as much cache
> >> invalidation traffic for temporary tables as we are doing? I think you
> >> are saying we are fine and there are no optimizations possible.
> >
> > Yeah, I think so. I mean, if you have a concrete example of this
> > causing a problem, then we can look into it, but my intuition is that
> > it's OK. Programmers intuition are notoriously wrong, of course, so
> > we're all just shooting in the dark until we have something to
> > measure.
>
> Sounds like there should be a comment somewhere in the code that
> explains why we actually need those messages...

Done.

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

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