Re: Tablespace-level Block Size Definitions

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

In response to

Browse pgsql-hackers by date

  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