Re: Shared invalidation cache messages for temporary tables

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Shared invalidation cache messages for temporary tables
Date: 2011-03-14 13:33:19
Message-ID: AANLkTim8JuSqoUwgcLgeqp0uf7x4nTGE0C2A7RmnDwHP@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-03-14 13:43:05 Re: Indent authentication overloading
Previous Message Robert Haas 2011-03-14 13:25:28 Re: Macros for time magic values