We could also go parallel in another direction - I have been mulling about
writing a "vectorized" bsearch which would use AVX2, where you look up 64
(or more likely 32, so tids also fit in 256bit vector) tids at a time.
The trickiest part is that the search can complete at different iteration
for
On Sun, Mar 14, 2021 at 4:22 PM Thomas Munro wrote:
> BTW I got around to trying this idea out for a specialised
> bsearch_itemptr() using a wide comparator, over here:
Cool!
I have another thing that should be considered when we revisit this
area in the future: maybe we should structure the bin
On Wed, Sep 9, 2020 at 7:33 AM Peter Geoghegan wrote:
> On Tue, Sep 8, 2020 at 1:23 AM Masahiko Sawada
> wrote:
> > > > I wonder if you would also see a speed-up with a bsearch() replacement
> > > > that is inlineable, so it can inline the comparator (instead of
> > > > calling it through a funct
On Wed, Mar 10, 2021 at 11:53 PM Peter Eisentraut
wrote:
>
> On 10.03.21 02:29, Masahiko Sawada wrote:
> >> There is no noticeable effect of inlining lazy_tid_reaped(). So it
> >> would be better to not do that.
> >
> > Attached the patch that doesn't inline lazy_tid_reaped().
>
> committed
Thank
On 10.03.21 02:29, Masahiko Sawada wrote:
There is no noticeable effect of inlining lazy_tid_reaped(). So it
would be better to not do that.
Attached the patch that doesn't inline lazy_tid_reaped().
committed
On Tue, Mar 9, 2021 at 9:57 AM Masahiko Sawada wrote:
>
> On Mon, Mar 8, 2021 at 7:16 PM Peter Eisentraut
> wrote:
> >
> > On 21.01.21 14:11, Masahiko Sawada wrote:
> > > Agreed. bsearch with bound check showed a reasonable improvement in my
> > > evaluation in terms of performance. Regarding mem
On Mon, Mar 8, 2021 at 7:16 PM Peter Eisentraut
wrote:
>
> On 21.01.21 14:11, Masahiko Sawada wrote:
> > Agreed. bsearch with bound check showed a reasonable improvement in my
> > evaluation in terms of performance. Regarding memory efficiency, we
> > can experiment with other methods later.
> >
>
On 21.01.21 14:11, Masahiko Sawada wrote:
Agreed. bsearch with bound check showed a reasonable improvement in my
evaluation in terms of performance. Regarding memory efficiency, we
can experiment with other methods later.
I've attached the patch that adds a bound check for encoded
itermpointers
On Wed, Jan 20, 2021 at 3:50 PM Peter Eisentraut
wrote:
>
> On 2020-10-30 02:43, Masahiko Sawada wrote:
> > Using the integer set is very memory efficient (5MB vs. 114MB in the
> > base case) and there is no 1GB limitation. Looking at the execution
> > time, I had expected that using the integer s
On 2020-10-30 02:43, Masahiko Sawada wrote:
Using the integer set is very memory efficient (5MB vs. 114MB in the
base case) and there is no 1GB limitation. Looking at the execution
time, I had expected that using the integer set is slower on recording
TIDs than using the simple array but in this
On Tue, 1 Sep 2020 at 05:56, Peter Geoghegan wrote:
>
> On Mon, Aug 31, 2020 at 12:22 PM Thomas Munro wrote:
> > On Sun, Aug 30, 2020 at 11:08 PM Masahiko Sawada
> > wrote:
> > > So my proposal is to add boundary value check in lazy_tid_reaped()
> > > before
On Tue, 1 Sep 2020 at 08:01, Peter Geoghegan wrote:
>
> On Mon, Aug 31, 2020 at 1:56 PM Peter Geoghegan wrote:
> > I wonder if Roaring bitmaps would work well for this:
> >
> > https://arxiv.org/abs/1709.07821
>
> Alternatively, perhaps we could use a negative cache of heap blocks
> that have no
On Tue, Sep 8, 2020 at 1:23 AM Masahiko Sawada
wrote:
> > > I wonder if you would also see a speed-up with a bsearch() replacement
> > > that is inlineable, so it can inline the comparator (instead of
> > > calling it through a function pointer). I wonder if something more
> > > like (lblk << 32
On Tue, 1 Sep 2020 at 04:44, Thomas Munro wrote:
>
> On Tue, Sep 1, 2020 at 7:21 AM Thomas Munro wrote:
> > On Sun, Aug 30, 2020 at 11:08 PM Masahiko Sawada
> > wrote:
> > > So my proposal is to add boundary value check in lazy_tid_reaped()
> > > before execu
On Mon, Aug 31, 2020 at 1:56 PM Peter Geoghegan wrote:
> I wonder if Roaring bitmaps would work well for this:
>
> https://arxiv.org/abs/1709.07821
Alternatively, perhaps we could use a negative cache of heap blocks
that have no tuples to kill at all. Maybe just a simple array whose
elements are
On Mon, Aug 31, 2020 at 12:22 PM Thomas Munro wrote:
> On Sun, Aug 30, 2020 at 11:08 PM Masahiko Sawada
> wrote:
> > So my proposal is to add boundary value check in lazy_tid_reaped()
> > before executing bsearch(3). This will help when index vacuum happens
> > multip
On Tue, Sep 1, 2020 at 7:21 AM Thomas Munro wrote:
> On Sun, Aug 30, 2020 at 11:08 PM Masahiko Sawada
> wrote:
> > So my proposal is to add boundary value check in lazy_tid_reaped()
> > before executing bsearch(3). This will help when index vacuum happens
> > multip
On Sun, Aug 30, 2020 at 11:08 PM Masahiko Sawada
wrote:
> So my proposal is to add boundary value check in lazy_tid_reaped()
> before executing bsearch(3). This will help when index vacuum happens
> multiple times or when garbage tuples are concentrated to a narrow
> range.
Makes s
e for glibc.
So my proposal is to add boundary value check in lazy_tid_reaped()
before executing bsearch(3). This will help when index vacuum happens
multiple times or when garbage tuples are concentrated to a narrow
range.
I’ve done three performance tests. maintenance_work_mem is set to 64MB
with whi
19 matches
Mail list logo
