On Mon, 15 Jan 2024 at 04:45, Tomas Vondra <tomas.von...@enterprisedb.com> wrote: > > On 1/14/24 12:18, vignesh C wrote: > > On Fri, 14 Jul 2023 at 20:17, Tomas Vondra > > <tomas.von...@enterprisedb.com> wrote: > >> > >> On 7/9/23 23:44, Tomas Vondra wrote: > >>> ... > >>>>> Yes, my previous message was mostly about backwards compatibility, and > >>>>> this may seem a bit like an argument against it. But that message was > >>>>> more a question "If we do this, is it actually backwards compatible the > >>>>> way we want/need?") > >>>>> > >>>>> Anyway, I think the BrinDesc scratch space is a neat idea, I'll try > >>>>> doing it that way and report back in a couple days. > >>>> > >>>> Cool. In 0005-Support-SK_SEARCHARRAY-in-BRIN-bloom-20230702.patch, you > >>>> used the preprocess function to pre-calculate the scankey's hash, even > >>>> for scalars. You could use the scratch space in BrinDesc for that, > >>>> before doing anything with SEARCHARRAYs. > >>>> > >>> > >>> Yeah, that's a good idea. > >>> > >> > >> I started looking at this (the scratch space in BrinDesc), and it's not > >> as straightforward. The trouble is BrinDesc is "per attribute" but the > >> scratch space is "per scankey" (because we'd like to sort values from > >> the scankey array). > >> > >> With the "new" consistent functions (that get all scan keys at once) > >> this probably is not an issue, because we know which scan key we're > >> processing and so we can map it to the scratch space. But with the old > >> consistent function that's not the case. Maybe we should support this > >> only with the "new" consistent function variant? > >> > >> This would however conflict with the idea to have a separate consistent > >> function for arrays, which "splits" the scankeys into multiple groups > >> again. There could be multiple SAOP scan keys, and then what? > >> > >> I wonder if the scratch space should be in the ScanKey instead? > > > > Are we planning to post an updated patch for this? If the interest has > > gone down and if there are no plans to handle this I'm thinking of > > returning this commitfest entry in this commitfest and can be opened > > when there is more interest. > > > > I still think the patch is a good idea and plan to get back to it, but > probably not in this CF. Given that the last update if from July, it's > fair to bump it - either RWF or just move to the next CF. Up to you.
I have changed the status to RWF, feel free to update the commitfest after handling the comments. Regards, Vignesh