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

From Tom Lane
Subject Re: Implementing cost limit/delays for insert/delete/update/select
Date
Msg-id 8578.1219705358@sss.pgh.pa.us
Whole thread Raw
In response to Re: Implementing cost limit/delays for insert/delete/update/select  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Implementing cost limit/delays for insert/delete/update/select
Re: Implementing cost limit/delays for insert/delete/update/select
List pgsql-hackers
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'm fairly dubious about this whole proposal: it's not clear to me that
the vacuum delay stuff works very well at all, and to the extent that it
does work it's because vacuum has such stylized, predictable behavior.
The same can't be said of general SQL queries.  For one thing, it's
not apparent that rate-limiting I/O would be sufficient, because
although vacuum is nearly always I/O bound, general queries often are
CPU bound; or their system impact might be due to other factors like
contention for shared-memory data structures.  Priority inversion is
a pretty serious concern as well (ie, a sleeping "low priority" query
might be blocking other queries).

I think this proposal is likely to lead to a large, invasive patch that
isn't actually very useful in the real world.

Oh, and I think the suggestion to modify SQL syntax for this is right
out.  A GUC setting might be a sane API.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Grant Finnemore
Date:
Subject: Proposal to sync SET ROLE and pg_stat_activity
Next
From: Tom Lane
Date:
Subject: Re: WIP patch: reducing overhead for repeat de-TOASTing