Re: Keeping temporary tables in shared buffers

On Thu, May 24, 2018 at 11:50 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2018-05-25 09:40:10 +0300, Heikki Linnakangas wrote:
> > On 25/05/18 09:25, Asim Praveen wrote:
> > > My parochial vision of the overhead is restricted to 4 * NBuffers of
> > > additional shared memory, as 4 bytes are being added to BufferTag.
> May I
> > > please get some enlightenment?
> >
> > Any extra fields in BufferTag make computing the hash more expensive.
> It's a
> > very hot code path, so any cycles spent are significant.
>
> Indeed, very much so.
>
> But I'm not sure we need anything in the tags themselves. We don't
> denote buffers for unlogged tables in the tag itself either. As Tom
> observed the oids for temp tables are either unique or can be made
> unique easy enough. And the temporaryness can be declared in a bit in
> the buffer header, rather than the tag itself. I don't see why a hash
> lookup would need to know that.
>

Currently, relfilenodes (specifically spcid,dbid,relfilenode) for temp and
regular tables can collide as temp files have "t_nnn" representation
on-disk. Due to this relfilenode allocation logic can assign same
relfilenode for temp and non-temp. If relfilenode uniqueness can be
achieved then need for adding anything to buffer tag goes away.

When starting to work on the radix tree stuff I had, to address the size
> of buffer tag issue you mention above, a prototype patch that created a
> shared 'relfilenode' table. That guaranteed that relfilenodes are
> unique. That'd work here as well, and would allow to get rid of a good
> chunk of uglyness we have around allocating relfilenodes right now (like
> not unlinking files etc).
>

That would be great!

>
> But more generally, I don't see why it'd be that problematic to just get
> rid of the backendid? I don't really see any technical necessity to have
> it.
>

Backendid was also added it seems due to same reason of not having unique
relfilnodes for temp tables. So, yes with uniqueness guaranteed this can go
away as well.