Re: Missing CFI in hlCover()? - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Missing CFI in hlCover()?
Date
Msg-id 20200730235034.GA12375@tamriel.snowman.net
Whole thread Raw
In response to Re: Missing CFI in hlCover()?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Missing CFI in hlCover()?  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: logtape.c stats don't account for unused "prefetched" block numbers
Next
From: Justin Pryzby
Date:
Subject: Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)