BUG #17494: High demand for displacement sort

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: pashutin(at)gmail(dot)com
Subject: BUG #17494: High demand for displacement sort
Date: 2022-05-24 11:04:18
Message-ID: 17494-3a8a5439edcbd4ec@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 17494
Logged by: Владимир Пашутин
Email address: pashutin(at)gmail(dot)com
PostgreSQL version: 11.14
Operating system: any
Description:

When working with sorting large lists, we often encounter an error:
SQL state [XX000]; error code [0]; ERROR: could not resize shared memory
segment \"/PostgreSQL.932873081\" to 100868096 bytes: Interrupted system
call; nested exception is org.postgresql.util.PSQLException: ERROR: could
not resize shared memory segment \"/PostgreSQL.932873081\" to 100868096
bytes: Interrupted system call
But we almost never need the whole list. Requests are always limited with
LIMIT and OFFSET.
However, from the analysis of the query plan, it turns out that first there
is a complete sorting of the entire result and only then the selection of
the required part of the rows.
The above error also confirms this assumption.
What can be done so that when sorting, the RAM contains only the limit +
offset of the lines and the records read from the disk that have passed the
filtering are checked for falling into the range of lines contained in the
memory, and only after that sorting with displacement is turned on?
This will drastically reduce memory requirements and significantly reduce
the number of comparison operations.

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Mats Kindahl 2022-05-24 12:10:36 Re: Use of signal-unsafe functions from signal handlers
Previous Message Juan José Santamaría Flecha 2022-05-24 11:00:55 Re: BUG #17492: error MSB4126: The specified solution configuration "Release|arm64" is invalid