From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Incremental sort |
Date: | 2017-04-27 14:23:44 |
Message-ID: | CAPpHfdtGzNUBo-vtqOhJuemnHVJWmz57jP=50U8YFi7==8MXKA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 27, 2017 at 5:06 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Apr 26, 2017 at 11:39 AM, Alexander Korotkov
> <a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> > But I'd like to make incremental sort not slower than quicksort in case
> of
> > presorted data. New idea about it comes to my mind. Since cause of
> > incremental sort slowness in this case is too frequent reset of
> tuplesort,
> > then what if we would artificially put data in larger groups. Attached
> > revision of patch implements this: it doesn't stop to accumulate tuples
> to
> > tuplesort until we have MIN_GROUP_SIZE tuples.
> >
> > Now, incremental sort is not slower than quicksort. And this seems to be
> > cool.
> > However, in the LIMIT case we will pay the price of fetching some extra
> > tuples from outer node. But, that doesn't seem to hurt us too much.
> >
> > Any thoughts?
>
> Nice idea.
Cool.
Than I'm going to make a set of synthetic performance tests in order to
ensure that there is no regression.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2017-04-27 14:23:56 | Re: PG 10 release notes |
Previous Message | Stephen Frost | 2017-04-27 14:17:26 | Re: pg_dump emits ALTER TABLE ONLY partitioned_table |