Re: Implementing cost limit/delays for insert/delete/update/select - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Implementing cost limit/delays for insert/delete/update/select
Date
Msg-id 871w0ca943.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Implementing cost limit/delays for insert/delete/update/select  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
>> You would have to test for whether it's time to sleep much more often.
>> Possibly before every ExecProcNode call would be enough.
>
> That would have overhead comparable to EXPLAIN ANALYZE, which is a lot.

I don't think the overhead would be anywhere near as much. He wouldn't have to
call gettimeofday() (except just after sleeping) which is what hurts EXPLAIN
ANLAYZE so much. Just count i/o operations.

In any case, if the point is to call sleep how much would do we care about
overhead? Do you think it would consume so much extra cpu that even after
sleeping for 10ms it would be a big resource drain for other processes?

The point about the invasiveness remains. If you want to count i/o operations
it means touching a lot of lower-level code. I'm interested in doing that
anyways to get better monitoring and profiling data though.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: WIP patch: reducing overhead for repeat de-TOASTing
Next
From: Tom Lane
Date:
Subject: Re: Proposal: new border setting in psql