Re: [HACKERS] CLUSTER command progress monitor
От | Tatsuro Yamada |
---|---|
Тема | Re: [HACKERS] CLUSTER command progress monitor |
Дата | |
Msg-id | ef582629-3723-296d-463d-5f475810df7f@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] CLUSTER command progress monitor (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On 2019/03/06 1:13, Robert Haas wrote: > On Tue, Mar 5, 2019 at 3:56 AM Tatsuro Yamada > <yamada.tatsuro@lab.ntt.co.jp> wrote: >>>> === Discussion points === >>>> >>>> - Progress counter for "3. sorting tuples" phase >>>> - Should we add pgstat_progress_update_param() in tuplesort.c like a >>>> "trace_sort"? >>>> Thanks to Peter Geoghegan for the useful advice! >>> >>> How would we avoid an abstraction violation? >> >> Hmm... What do you mean an abstraction violation? >> If it is difficult to solve, I'd not like to add the progress counter for the sorting tuples. > > What I mean is... I think it would be useful to have this counter, but > I'm not sure how the tuplesort code would know to update the counter > in this case and not in other cases. The tuplesort code is used for > lots of things; we can't update a counter for CLUSTER if the tuplesort > is being used for CREATE INDEX or a Sort node in a query or whatever. > So my question is how we would indicate to the tuplesort that it needs > to do the counter update, and whether that would end up making for > ugly code. Thanks for your explanation! I understood that now. I guess it means an API to get a progress for sort processing, so let us just put it aside now. I'd like to leave that as is for an appropriate person. Regards, Tatsuro Yamada
В списке pgsql-hackers по дате отправления: