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? regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
