Skip site navigation (1) Skip section navigation (2)

Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vincent van Leeuwen <pgsql(dot)spam(at)vinz(dot)nl>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning
Date: 2003-06-10 19:43:47
Message-ID: 4332.1055274227@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Vincent van Leeuwen <pgsql(dot)spam(at)vinz(dot)nl> writes:
> Halving the cpu_tuple_cost has given a very impressive performance boost
> (performance roughly doubled). I'm not sure why, because the plans of the
> large queries I was checking haven't changed as far as I can see, but maybe
> some smaller queries I didn't bother to check are using a different plan now.

That's very curious; I'd expect that parameter to have only marginal
effect in the first place (unless you make huge changes in it, of course).
It must have changed some plan that you didn't take note of.  If you can
find it I'd be interested to know.

> Just to be absolutely sure: all *_cost parameters only influence the
> chosen plan, right? There is absolutely nothing else influenced which
> doesn't show up in an EXPLAIN ANALYZE, right?

AFAIR, the only one of these parameters that the executor pays any
attention to is SORT_MEM; that will determine how soon the runtime code
starts to spill tuples to disk in sorts, hash tables, etc.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Joe ConwayDate: 2003-06-10 20:05:14
Subject: Re: Re-ordering .CONF params ... questions for this list
Previous:From: Jim C. NasbyDate: 2003-06-10 19:42:07
Subject: Re: Hash or merge join instead of inner loop

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group