On Mon, 15 Jan 2024 at 04:45, Tomas Vondra
wrote:
>
> On 1/14/24 12:18, vignesh C wrote:
> > On Fri, 14 Jul 2023 at 20:17, Tomas Vondra
> > wrote:
> >>
> >> On 7/9/23 23:44, Tomas Vondra wrote:
> >>> ...
> > Yes, my previous message was mostly about backwards compatibility, and
> > this m
On 1/14/24 12:18, vignesh C wrote:
> On Fri, 14 Jul 2023 at 20:17, Tomas Vondra
> 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
>
On Fri, 14 Jul 2023 at 20:17, Tomas Vondra
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 ac
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?")
>>>
>>>
On 7/9/23 20:05, Heikki Linnakangas wrote:
> On 09/07/2023 19:16, Tomas Vondra wrote:
>> On 7/8/23 23:57, Heikki Linnakangas wrote:
>>> The new preprocess support function feels a bit too inflexible to me.
>>> True, you can store whatever you want in the ScanKey that it returns,
>>> but since that'
On 09/07/2023 19:16, Tomas Vondra wrote:
On 7/8/23 23:57, Heikki Linnakangas wrote:
The new preprocess support function feels a bit too inflexible to me.
True, you can store whatever you want in the ScanKey that it returns,
but since that's the case, why not just make it void * ? It seems that
t
On 7/8/23 23:57, Heikki Linnakangas wrote:
> On 02/07/2023 19:09, Tomas Vondra wrote:
>> Here's an updated version of the patch series.
>>
>> I've polished and pushed the first three patches with cleanup, tests to
>> improve test coverage and so on. I chose not to backpatch those - I
>> planned to
On 02/07/2023 19:09, Tomas Vondra wrote:
Here's an updated version of the patch series.
I've polished and pushed the first three patches with cleanup, tests to
improve test coverage and so on. I chose not to backpatch those - I
planned to do that to make future backpatches simpler, but the chang
On 2/24/23 22:07, Heikki Linnakangas wrote:
> I had a quick look at just the preliminary cleanup patches:
>
>> 0001-BRIN-bloom-cleanup-20230218.patch
>
> Looks good to me
>
>> 0002-BRIN-minmax-multi-cleanup-20230218.patch
>
> Looks good, although it would feel more natural to me to do it the ot
I had a quick look at just the preliminary cleanup patches:
0001-BRIN-bloom-cleanup-20230218.patch
Looks good to me
0002-BRIN-minmax-multi-cleanup-20230218.patch
Looks good, although it would feel more natural to me to do it the other
way round, and define 'matches' as 'bool matches', and
Hi,
while experimenting with BRIN indexes after a couple FOSDEM discussions,
I ran into the existing limitation that BRIN indexes don't handle array
scan keys. So BRIN indexes can be used for conditions like
WHERE a IN (1,2,3,4,5)
but we essentially treat the values as individual scan keys,
11 matches
Mail list logo
