Re: Reducing the size of BufferTag & remodeling forks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reducing the size of BufferTag & remodeling forks
Date
Msg-id 14196.1435845119@sss.pgh.pa.us
Whole thread Raw
In response to Reducing the size of BufferTag & remodeling forks  (Andres Freund <andres@anarazel.de>)
Responses Re: Reducing the size of BufferTag & remodeling forks  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> 1) Introduce a shared pg_relfilenode table. Every table, even
>    shared/nailed ones, get an entry therein. It's there to make it
>    possibly to uniquely allocate relfilenodes across databases &
>    tablespaces.
> 2) Replace relation forks, with the exception of the init fork which is
>    special anyway, with separate relfilenodes. Stored in seperate
>    columns in pg_class.

> Thoughts?

I'm concerned about the traffic and contention involved with #1.
I'm also concerned about the assumption that relfilenode should,
or even can be, unique across an entire installation.  (I suppose
widening it to 8 bytes would fix some of the hazards there, but
that bloats your buffer tag again.)

But here's the big problem: you're talking about a huge amount of
work for what seems likely to be a microscopic improvement in some
operations.  Worse, we'll be taking penalties for other operations.
How will you do DropDatabaseBuffers() for instance?

CREATE DATABASE is going to be a problem, too.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Heikki Linnakangas
Date:
Subject: Re: drop/truncate table sucks for large values of shared buffers