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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Implementing cost limit/delays for insert/delete/update/select
Дата
Msg-id 8578.1219705358@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Implementing cost limit/delays for insert/delete/update/select  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: Implementing cost limit/delays for insert/delete/update/select  (Gregory Stark <stark@enterprisedb.com>)
Re: Implementing cost limit/delays for insert/delete/update/select  (Peter Schuller <peter.schuller@infidyne.com>)
Список 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 по дате отправления:

Предыдущее
От: Grant Finnemore
Дата:
Сообщение: Proposal to sync SET ROLE and pg_stat_activity
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WIP patch: reducing overhead for repeat de-TOASTing