Re: Reducing the size of BufferTag & remodeling forks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Reducing the size of BufferTag & remodeling forks
Date: 2015-07-02 13:51:59
Message-ID: 14196.1435845119@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2015-07-02 13:57:58 Re: drop/truncate table sucks for large values of shared buffers
Previous Message Simon Riggs 2015-07-02 13:48:50 Re: Support for N synchronous standby servers - take 2