Re: including backend ID in relpath of temp rels - updated patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: including backend ID in relpath of temp rels - updated patch
Date
Msg-id 6488.1281114886@sss.pgh.pa.us
Whole thread Raw
In response to Re: including backend ID in relpath of temp rels - updated patch  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: including backend ID in relpath of temp rels - updated patch
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Aug 5, 2010 at 7:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> One thing that I find rather distressing about this is the 25% bloat
>> in sizeof(SharedInvalidationMessage). �Couldn't we avoid that? �Is it
>> really necessary to *ever* send an SI message for a backend-local rel?

> It can be dropped or unlinked by another backend, so, yes.

Really?  Surely that should be illegal during normal operation.  We
might be doing such during crash recovery, but we don't need to
broadcast sinval messages then.

It might be sufficient to consider that there are "local" and "global"
smgr inval messages, where the former never get out of the generating
backend, so a bool is enough in the message struct.

> had was that if we could count on the backend ID to fit into an int16
> we could fit it in to what's currently padding space.  That would
> require rather dramatically lowering the maximum number of backends
> (currently INT_MAX/4), but it's a little hard to imagine that we can
> really support more than 32,767 simultaneous backends anyway.

Yeah, that occurred to me too.  A further thought is that the id field
could probably be reduced to 1 byte, leaving 3 for backendid, which
would certainly be plenty.  However representing that in a portable
struct declaration would be a bit painful I fear.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Initial review of xslt with no limits patch
Next
From: Pavel Stehule
Date:
Subject: Re: Initial review of xslt with no limits patch