| From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Ankit Kumar Pandey <itsankitkp(at)gmail(dot)com>, pghackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Vik Fearing <vik(at)postgresfriends(dot)org> |
| Subject: | Re: Todo: Teach planner to evaluate multiple windows in the optimal order |
| Date: | 2023-02-16 11:28:23 |
| Message-ID: | CAFBsxsESDRxMZA8LxYFSFQcd8jcyyvNxOHP2EDtn3YCN9ENSKw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 16, 2023 at 10:03 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> I suspect it's slower because the final sort must sort the entire
> array still without knowledge that portions of it are pre-sorted. It
> would be very interesting to improve this and do some additional work
> and keep track of the "memtupsortedto" index by pushing them onto a
> List each time we cross the availMem boundary, then do then qsort just
> the final portion of the array in tuplesort_performsort() before doing
> a k-way merge on each segment rather than qsorting the entire thing
> again. I suspect this would be faster when work_mem exceeds L3 by some
> large amount.
Sounds like a reasonable thing to try.
It seems like in-memory merge could still use abbreviation, unlike external
merge.
--
John Naylor
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jelte Fennema | 2023-02-16 11:31:46 | Re: [PATCH] Align GSS and TLS error handling in PQconnectPoll() |
| Previous Message | Amit Kapila | 2023-02-16 11:00:09 | Re: Change xl_hash_vacuum_one_page.ntuples from int to uint16 |