Re: How much expensive are row level statistics? - Mailing list pgsql-performance

From Kevin Brown
Subject Re: How much expensive are row level statistics?
Date
Msg-id 20051216054457.GC691@filer
Whole thread Raw
In response to Re: How much expensive are row level statistics?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Tom Lane wrote:
> Michael Fuhr <mike@fuhr.org> writes:
> > Does the backend support, or could it be easily modified to support,
> > a mechanism that would post the command string after a configurable
> > amount of time had expired, and then continue processing the query?
>
> Not really, unless you want to add the overhead of setting a timer
> interrupt for every query.  Which is sort of counterproductive when
> the motivation is to reduce overhead ...
>
> (It might be more or less free if you have statement_timeout set, since
> there would be a setitimer call anyway.  But I don't think that's the
> norm.)

Actually, it's probably not necessary to set the timer at the
beginning of every query.  It's probably sufficient to just have it go
off periodically, e.g. once every second, and thus set it when the
timer goes off.  And the running command wouldn't need to be re-posted
if it's the same as last time around.  Turn off the timer if the
connection is idle now and was idle last time around (or not, if
there's no harm in having the timer running all the time), turn it on
again at the start of the next transaction.

In essence, the backend would be "polling" itself every second or so
and recording its state at that time, rather than on every
transaction.

Assuming that doing all that wouldn't screw something else up...



--
Kevin Brown                          kevin@sysexperts.com

pgsql-performance by date:

Previous
From: "Craig A. James"
Date:
Subject: Re: Overriding the optimizer
Next
From: Kevin Brown
Date:
Subject: Re: Overriding the optimizer