Re: Tablespace-level Block Size Definitions - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Tablespace-level Block Size Definitions
Date
Msg-id 1117583839.3844.828.camel@localhost.localdomain
Whole thread Raw
In response to Re: Tablespace-level Block Size Definitions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 2005-05-31 at 17:05 -0400, Tom Lane wrote:
> "Jonah H. Harris" <jharris@tvi.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



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Quick-and-dirty compression for WAL backup blocks
Next
From: "Luke Lonergan"
Date:
Subject: Re: Consumer-grade vs enterprise-grade disk drives