From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Missing CFI in hlCover()? |
Date: | 2020-07-30 14:37:56 |
Message-ID: | 20200730143756.GY12375@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2020-07-30 16:21:23 | Re: HyperLogLog.c and pg_leftmost_one_pos32() |
Previous Message | Tom Lane | 2020-07-30 14:37:20 | Re: Missing CFI in hlCover()? |