pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #17494: High demand for displacement sort
2+ messages / 2 participants
[nested] [flat]
* BUG #17494: High demand for displacement sort
@ 2022-05-24 11:04 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 2+ messages in thread
From: PG Bug reporting form @ 2022-05-24 11:04 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: pashutin@gmail.com
The following bug has been logged on the website:
Bug reference: 17494
Logged by: Владимир Пашутин
Email address: pashutin@gmail.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.
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: BUG #17494: High demand for displacement sort
@ 2022-05-24 19:44 Jeff Janes <jeff.janes@gmail.com>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 0 replies; 2+ messages in thread
From: Jeff Janes @ 2022-05-24 19:44 UTC (permalink / raw)
To: pashutin@gmail.com, pgsql-bugs <pgsql-bugs@lists.postgresql.org>
On Tue, May 24, 2022, 8:37 AM PG Bug reporting form <noreply@postgresql.org>
wrote:
> The following bug has been logged on the website:
>
> Bug reference: 17494
> Logged by: Владимир Пашутин
> Email address: pashutin@gmail.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.
>
This is not much of a bug report. PostgreSQL does have top-N sorts. Why
it is not used for some particular query is impossible to say without
seeing the query and/or query plan.
Even if not using top-N, it should still spill to disk instead of erroring
out like that, assuming your memory/parallel settings and load are
reasonable for your server. Again, with this amount of detail there is no
way to know.
Cheers,
Jeff
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2022-05-24 19:44 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-05-24 11:04 BUG #17494: High demand for displacement sort PG Bug reporting form <noreply@postgresql.org>
2022-05-24 19:44 ` Jeff Janes <jeff.janes@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox