| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com> |
| Cc: | James Coleman <jtc331(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Shaun Thomas <shaun(dot)thomas(at)2ndquadrant(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
| Date: | 2019-06-24 16:51:16 |
| Message-ID: | CANP8+j+HOE8d7KknKE60iFKRZDsqoCMRi4uwm1RTSu3gLSgcnw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 5 Jun 2019 at 17:14, Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com> wrote:
> Regarding this, I came across this,
> /*
> * Incremental sort can't be used with either EXEC_FLAG_REWIND,
> * EXEC_FLAG_BACKWARD or EXEC_FLAG_MARK, because we hold only current
> * bucket in tuplesortstate.
> */
> I think that is quite understandable. How are you planning to support
> backwards scan for this? In other words, when will incremental sort be
> useful for backward scan.
>
We stopped materializing the sort by default about 15 years ago because it
wasn't a common use case and it was very expensive for large sorts.
It's no real problem if incremental sorts don't support backwards scans -
we just won't use incremental in that case.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2019-06-24 16:56:04 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
| Previous Message | John Naylor | 2019-06-24 16:01:16 | Re: benchmarking Flex practices |