> On 24 Jun 2021, at 18:21, Matthias van de Meent
> wrote:
>
> On Thu, 17 Jun 2021 at 17:14, Matthias van de Meent
> wrote:
>>
>> I'll try to
>> benchmark the patches in this patchset (both 0001, and 0001+0002) in
>> the upcoming weekend.
>
> Somewhat delayed, benchmark results are attached.
On Thu, 17 Jun 2021 at 17:14, Matthias van de Meent
wrote:
>
> I'll try to
> benchmark the patches in this patchset (both 0001, and 0001+0002) in
> the upcoming weekend.
Somewhat delayed, benchmark results are attached. These are based on 7
iterations of the attached benchmark script ('scratch.sq
On Fri, 23 Apr 2021 at 12:45, Matthias van de Meent
wrote:
>
> On Sat, 17 Apr 2021 at 01:05, Peter Geoghegan wrote:
>
> > It would be convenient if the first patch could be treated
> > as an independent thing.
>
> Patch 0002 was the reason for writing 0001, and uses the performance
> improvements
On Sat, 17 Apr 2021 at 01:05, Peter Geoghegan wrote:
>
> On Fri, Apr 16, 2021 at 2:20 PM Matthias van de Meent
> wrote:
> > > Interesting approach. I think that in an ideal world we would have a
> > > tuple format with attribute lengths/offsets right in the header.
> >
> > I believe that that wou
On Fri, Apr 16, 2021 at 2:20 PM Matthias van de Meent
wrote:
> > Interesting approach. I think that in an ideal world we would have a
> > tuple format with attribute lengths/offsets right in the header.
>
> I believe that that would indeed be ideal w.r.t. access speed, but
> also quite expensive w
On Fri, 16 Apr 2021 at 18:03, Peter Geoghegan wrote:
>
> On Thu, Apr 15, 2021 at 11:06 AM Matthias van de Meent
> wrote:
> > I've noticed there are a lot of places in the btree index
> > infrastructure (and also some other index AMs) that effectively
> > iterate over the attributes of the index t
On Thu, Apr 15, 2021 at 11:06 AM Matthias van de Meent
wrote:
> I've noticed there are a lot of places in the btree index
> infrastructure (and also some other index AMs) that effectively
> iterate over the attributes of the index tuple, but won't use
> index_deform_tuple for reasons. However, thi
-- Targeting PG15; if too early / noise then please ignore.
I've noticed there are a lot of places in the btree index
infrastructure (and also some other index AMs) that effectively
iterate over the attributes of the index tuple, but won't use
index_deform_tuple for reasons. However, this implies
