Hello,
[ I have not yet had the time to look at code again in response to
some of the points raised raised by several people; but I wanted to
follow-up somewhat still on other bits. ]
> > You would have to test for whether it's time to sleep much more often.
> > Possibly before every ExecProcNode
On Mon, 2008-08-25 at 22:39 +0200, Peter Schuller wrote:
> Does this sound vaguely sensible? Is there an obvious show-stopper I
> am missing?
This was a well structured proposal.
The main problem is where you put the delay_point() calls. If you put
them at the top of the executor then you will
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> 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 do
Gregory Stark <[EMAIL PROTECTED]> 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'm fairly dubious about this whole proposal: it's
Btw, I forgot to mention in my original post that one interesting use
case that is not application specific, is to apply cost limits on
pg_dump. That would be one of the final goals for me.
> I think the experience with vacuum was that cost_delay was a mistake. The only
> parameter users really ou
On Mon, 25 Aug 2008 22:39:54 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> But I think we should consider removing the {auto,}vacuum_cost_delay
> parameter or at least hiding and undocumenting it. It's a foot-gun
> and serves no useful purpose that merely lowering the
> {auto,}vacuum_cost_limi
"Peter Schuller" <[EMAIL PROTECTED]> writes:
> Hello,
>
> I'd like to have a stab at implementing cost delays, for regular
> INSERT/DELETE/UPDATE/SELECT. The motivation is roughly the same as for
> VACUUM and the autovacuum limits; one may have application specific
> bulk operations that need exec
Hello,
I'd like to have a stab at implementing cost delays, for regular
INSERT/DELETE/UPDATE/SELECT. The motivation is roughly the same as for
VACUUM and the autovacuum limits; one may have application specific
bulk operations that need executing without adverseley affecting
latency/throughput of
