Re: Tablespace-level Block Size Definitions

From: Alvaro Herrera <alvherre(at)surnet(dot)cl>
To: "Jonah H(dot) Harris" <jharris(at)tvi(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Tablespace-level Block Size Definitions
Date: 2005-05-31 21:10:34
Message-ID: 20050531211033.GA10621@surnet.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 31, 2005 at 02:55:29PM -0600, Jonah H. Harris wrote:
> Hey everyone,
>
> I'm sure this has been thought of but was wondering whether anyone had
> discussed the allowance of run-time block size specifications at the
> tablespace level? I know that a change such as this would substantially
> impact buffer operations, transactions, access methods, the storage
> manager, and a lot of other stuff, however it would give an
> administrator the ability to inhance performance for specific applications.

The problem I see with this proposal is that the buffer manager knows
how to handle only a equally-sized pages. And the shared memory stuff
gets sized according to size * num_pages. So what happens if a certain
tablespace A with pagesize=X gets to have a lot of its pages cached,
evicting pages from tablespace B with pagesize=Y, where Y < X?

While I think it could be workable to make the buffer manager handle
variable-sized pages, it could prove difficult to handle the shared
memory. (We can't resize it while the server is running.)

--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"La principal característica humana es la tontería"
(Augusto Monterroso)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-05-31 21:24:12 Re: Deadlock with tsearch2 index ...
Previous Message Jonah H. Harris 2005-05-31 21:05:34 Re: Tablespace-level Block Size Definitions