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)
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 |