Re: Missing CFI in hlCover()?

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Missing CFI in hlCover()?
Дата
Msg-id 20200730235034.GA12375@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Missing CFI in hlCover()?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Missing CFI in hlCover()?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> Stephen Frost <sfrost@snowman.net> writes:
> >>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >>>> We could hard-code a rule like that, or we could introduce a new
> >>>> explicit parameter for the maximum cover length.  The latter would be
> >>>> more flexible, but we need something back-patchable and I'm concerned
> >>>> about the compatibility hazards of adding a new parameter in minor
> >>>> releases.  So on the whole I propose hard-wiring a multiplier of,
> >>>> say, 10 for both these cases.
>
> >>> That sounds alright to me, though I do think we should probably still
> >>> toss a CFI (or two) in this path somewhere as we don't know how long
> >>> some of these functions might take...
>
> >> Yeah, of course.  I'm still leaning to doing that in TS_execute_recurse.
>
> > Works for me.
>
> Here's a proposed patch along that line.

I've back-patched this to 11 (which was just a bit of fuzz) and tested
it out with a couple of different queries that were causing issues
previously on the archive server, and they finish in a much more
reasonable time and react faster to cancel requests/signals.

If you'd like to play with it more, the PG11 installed on ark2 now has
this patch built into it.

So, looks good to me, and would certainly be nice to get this into the
next set of releases, so the archive server doesn't get stuck anymore.
:)

Thanks!

Stephen

Вложения

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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: logtape.c stats don't account for unused "prefetched" block numbers
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)