Re: [HACKERS] Small improvement to compactify_tuples

From: Юрий Соколов <funny(dot)falcon(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Claudio Freire <klaussfreire(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Sokolov Yura <funny(dot)falcon(at)postgrespro(dot)ru>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Small improvement to compactify_tuples
Date: 2017-11-28 07:46:21
Message-ID: CAL-rCA2cCyvapkb15fADR3qKsRMo+XimPgmGviur1ui-y0q-aQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2017-11-08 23:44 GMT+03:00 Юрий Соколов <funny(dot)falcon(at)gmail(dot)com>:
>
> 2017-11-08 20:02 GMT+03:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> >
> > Claudio Freire <klaussfreire(at)gmail(dot)com> writes:
> > > What's perhaps not clear is whether there are better ideas. Like
> > > rebuilding the page as Tom proposes, which doesn't seem like a bad
> > > idea. Bucket sort already is O(bytes), just as memcopy, only it has a
> > > lower constant factor (it's bytes/256 in the original patch), which
> > > might make copying the whole page an extra time lose against bucket
> > > sort in a few cases.
> >
> > > Deciding that last point does need more benchmarking. That doesn't
> > > mean the other improvements can't be pursued in the meanwhile, right?
> >
> > Well, I doubt we're going to end up committing more than one of these
> > ideas. The question is which way is best. If people are willing to
> > put in the work to test all of them, let's do it.
> >
> > BTW, it strikes me that in considering the rebuild-the-page approach,
> > we should not have blinders on and just measure the speed of
> > PageRepairFragmentation. Rather, we should take a look at what happens
> > subsequently given a physically-ordered set of tuples. I can recall
> > Andres or someone moaning awhile ago about lack of locality of access in
> > index page searches --- maybe applying that approach while vacuuming
> > indexes will help?
> >
> > regards, tom lane
>
> I'd like to add qsort_template.h as Claudio suggested, ie in a way close
to
> simplehash.h. With such template header, there will be no need in
> qsort_tuple_gen.pl .

Attached patched replaces gen_qsort_tuple.pl with qsort_template.h - generic
qsort template header.
Some tests do not specify exact order (ie their output depends on order of
equal elements). Such tests output wes fixed.

I didn't apply this qsort to compactify_tuples yet. Will do soon.

With regards,
Sokolov Yura aka funny_falcon.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2017-11-28 08:14:19 Re: Transform for pl/perl
Previous Message Antonin Houska 2017-11-28 07:38:52 Re: [HACKERS] Transactions involving multiple postgres foreign servers