Re: benchmarking the query planner (was Re: Simple postgresql.conf wizard) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: benchmarking the query planner (was Re: Simple postgresql.conf wizard)
Date
Msg-id 603c8f070812080902u7aee4fc9y40d0847a737604b7@mail.gmail.com
Whole thread Raw
In response to Re: benchmarking the query planner (was Re: Simple postgresql.conf wizard)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Dec 8, 2008 at 11:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Stark <greg.stark@enterprisedb.com> writes:
>> That might only be the case when the pg_statistic record is in shared
>> buffers.
>
> Yeah, it seems unlikely that disabling compression is a good idea in the
> bigger scheme of things.

Is there any way to figure out what sort of compression ratios we're
typically getting?  The only way compression can really be a win is if
it's saving us having to read in additional pages.

Even then, I'm not sure we should worry about needing to read in
additional pages in this case.  I would sure expect statistics to stay
in shared buffers, or at least in the operating system cache.  Sure,
if the table is accessed VERY infrequently, that might not be the
case, but is that really what we want to optimize for?

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: benchmarking the query planner (was Re: Simple postgresql.conf wizard)
Next
From: Decibel!
Date:
Subject: Re: WIP: default values for function parameters