Re: [PROPOSAL] DIAGNOSTICS = SKIPPED_ROW_COUNT

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [PROPOSAL] DIAGNOSTICS = SKIPPED_ROW_COUNT
Дата
Msg-id CAKFQuwYR0zOB9PZTky19BtMWBRCfZvsnp327fAUuNFLQYo4u=g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PROPOSAL] DIAGNOSTICS = SKIPPED_ROW_COUNT  (dinesh kumar <dineshkumar02@gmail.com>)
Ответы Re: [PROPOSAL] DIAGNOSTICS = SKIPPED_ROW_COUNT  (dinesh kumar <dineshkumar02@gmail.com>)
Список pgsql-hackers

> Using this attribute, we can have more control on parallel operations like,

> IF SKIPPED_ROW_COUNT =0 THEN
> <<Treat me as, a complete transaction, and do below stuff>>
> ELSE
> <<Got only few tuples than required, and do below stuff>>
> END IF;

Um ... so what?  This is not a use-case.


In my view, "How one can be sure that, he obtained all the tuples with SKIP LOCKED". If the end user has this counter value, he may proceed with a different approach with partially locked tuples.


​Can you be more specific?  In most cases I can come up with (queues, basically) where skipped locked is running the processing performing the query is going to re-query the database on the next tick regardless of whether they thought they say only some or all of the potential rows on the prior pass.

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amir Rohan
Дата:
Сообщение: Re: Memory prefetching while sequentially fetching from SortTuple array, tuplestore
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_ctl/pg_rewind tests vs. slow AIX buildfarm members