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

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'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