| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
| 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:06:52 |
| Message-ID: | CA+TgmoZOa=ggP7k08=rNVHV_eBtJ9yBvpv93SUaZMtOcK7fYLQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2017-04-27 14:13:32 | Re: PG 10 release notes |
| Previous Message | Huong Dangminh | 2017-04-27 14:05:33 | Re: [PostgreSQL 10] default of hot_standby should be "on"? |