Re: Has anybody think about changing BLCKSZ to an option of initdb?

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, jd(at)commandprompt(dot)com, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Jacky Leng <lengjianquan(at)163(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Has anybody think about changing BLCKSZ to an option of initdb?
Date: 2009-03-14 18:31:51
Message-ID: 49BBF817.6010401@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> So has anyone here done any experiments with live systems with different block
>> sizes? What were your experiences?

Mark tested this back in the OSDL days. His findings on DBT2 was that
the right *combination* of OS and PG blocksizes gave up to a 5%
performance increase, I think. Hardly enough to make it worth the
headache of running with non-default PG and non-deafault Linux block
sizes, especially since the wrong combination resulted in a decrease in
performance, sometimes dramatically so.

However, at Greenplum I remember determining that larger PG block sizes,
if matched with larger filesystem block sizes did significantly help on
performance of data warehouses which do a lot of seq scans -- but that
our ceiling of 32K was still too small to really make this work. I
don't have the figures for that, though; Luke reading this?

--Josh

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2009-03-14 18:34:24 Re: parallel restore item dependencies
Previous Message Gurjeet Singh 2009-03-14 18:30:20 Re: log : bad file dscriptor????