Re: Tablespace-level Block Size Definitions

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Tablespace-level Block Size Definitions
Дата
Msg-id 1117583839.3844.828.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: Tablespace-level Block Size Definitions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Quick-and-dirty compression for WAL backup blocks
Следующее
От: "Luke Lonergan"
Дата:
Сообщение: Re: Consumer-grade vs enterprise-grade disk drives