Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Bykov Ivan <i.bykov@modernsys.ru>, Sami Imseih <samimseih@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2025-03-13T21:52:08Z
Lists: pgsql-hackers
Attachments
- jumbletime.patch.txt (text/plain)
- jumble_results.txt (text/plain)
On Tue, 11 Mar 2025 at 20:48, David Rowley <dgrowleyml@gmail.com> wrote: > Since then, I see that Ivan > has already submitted a patch that accounts for NULL nodes and adds a > byte to the jumble buffer to account for NULLs. This seems quite clean > and simple. However, Sami seems to have concerns about the overhead of > doing this. Is that warranted at all? Potentially, there could be a > decent number of NULL fields. It'll probably be much cheaper than the > offsetof idea I came up with. To try and get some timing information about the overhead added for jumbling the NULLs, I compared master and the patch at [1] using the attached jumbletime.patch.txt. The patch just adds an additional call to JumbleQuery and times how long it takes and outputs the result in nanoseconds. Running make check has the advantage of trying out many different queries. On an AMD 3990x machine, the results for jumbling all make check queries are: master: 73.66 milliseconds 0001-Query-ID-Calculation-Fix-Variant-B.patch: 80.36 milliseconds So that adds about 9.1% overhead to jumbling, on average. See the attached jumble_results.txt for full results and the code to extract the results. David [1] https://www.postgresql.org/message-id/attachment/173439/0001-Query-ID-Calculation-Fix-Variant-B.patch
Commits
-
Optimize Query jumble
- ad9a23bc4f51 18.0 landed