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

Re: Implementing cost limit/delays for insert/delete/update/select

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Peter Schuller" <peter(dot)schuller(at)infidyne(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Implementing cost limit/delays for insert/delete/update/select
Date: 2008-08-26 00:54:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)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
  Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-08-26 01:05:10
Subject: Re: Proposal: new border setting in psql
Previous:From: Tom LaneDate: 2008-08-26 00:54:28
Subject: Re: WIP patch: reducing overhead for repeat de-TOASTing

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