From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Jonah H(dot) Harris" <jharris(at)tvi(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Tablespace-level Block Size Definitions |
Date: | 2005-05-31 23:57:19 |
Message-ID: | 1117583839.3844.828.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2005-05-31 at 17:05 -0400, Tom Lane wrote:
> "Jonah H. Harris" <jharris(at)tvi(dot)edu> writes:
> > 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?
>
> Can you produce any evidence whatsoever that this could be worth the cost?
> Aside from the nontrivial development effort needed, there would be
> runtime inefficiencies created --- for instance, inefficient use of
> buffer pool storage because it'd no longer be true that any buffer could
> hold any block. Without some pretty compelling evidence, I wouldn't
> even waste any time thinking about it ...
DB2 has had multiple page size support for some time, though the default
was always 4KB. They have just reintroduced the option to have a single
page size > 4KB across the database. They would not do this if there was
not clear evidence that multiple block sizes were inefficient in some
reasonably common cases.
I must admit when I cam here, I thought the same as Jonah. But the I
haven't seen any recent evidence for any benefit. Its a real pain trying
to test this and very difficult to change once its been setup. There's a
great deal more benefit to be had from many other areas, IMHO.
Best Regards, Simon Riggs
From | Date | Subject | |
---|---|---|---|
Next Message | Luke Lonergan | 2005-06-01 00:10:06 | Re: Consumer-grade vs enterprise-grade disk drives |
Previous Message | Simon Riggs | 2005-05-31 23:32:47 | Re: Quick-and-dirty compression for WAL backup blocks |