Re: Keeping temporary tables in shared buffers

On Thu, May 24, 2018 at 8:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> So then you have to think about how to transition smoothly between "rel
> is in local buffers" and "rel is in shared buffers", bearing in mind that
> ever having the same page in two different buffers would be disastrous.

Local buffers would not be used at all if temp tables start residing in
shared buffers. The transition mentioned above shouldn't be needed.

>
> I think that would be a deal breaker right there, because of the
> distributed overhead of making the tags bigger. However, I don't
> actually understand why you would need to do that. Temp tables
> have unique OIDs/relfilenodes anyway, don't they? Or if I'm
> misremembering and they don't, couldn't we make them so?

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?

Temp tables have unique filename on disk: t_<backendID>_<relfilenode>. The
logic to assign OIDs and relfilenodes, however, doesn't differ. Given a
RelFileNode, it is not possible to tell if it's a temp table or not.
RelFileNodeBackend allows for that distinction but it's not used by buffer
manager.

>
> taking a performance hit to avoid it could be a net loss. The only reason
> why you'd care about writing at all is to try to make the buffers clean
> in case they have to be reclaimed for some other use --- and if the
> checkpointer does such a write instead of the bgwriter, why's that bad?

Yes, a temp table's buffer would need to be written out only if it needs to
be repurposed for a different page. It is not bad, our description wasn't
clear enough.

Asim