Re: Feature-Request: Performance-Optimization when using limit in combination with order by on querys using union

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Karsten P <mr(dot)mister123(at)hotmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Feature-Request: Performance-Optimization when using limit in combination with order by on querys using union
Date: 2025-05-08 13:43:27
Message-ID: CAApHDvqiUJLw02dM-54BmgvjKjNcOVLS98pM4tkmGtLVRFx8Ww@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 8 May 2025 at 22:57, Karsten P <mr(dot)mister123(at)hotmail(dot)com> wrote:
> i'm sorry i didn't check that first. it just won't work in my real-life
> example.
> though each part of the query is using an index-scan it is than using a
> 'normal' append
> instead of a merge-append, but i don't know why.

You could try:

SET enable_sort = 0;

... to see what the costs come out to be and how it performs. Perhaps
the planner thinks using the other indexes to more efficiently filter
out the unrelated tuples for the WHERE clause is cheaper than using
the index that provides the tuples sorted by date and filtering the
unwanted tuples with a "Filter".

> so my question is: under wich circumstance does the query-planner use or
> prefer the 'merge append' over 'append'?

It's all based on costs. Those are shown in the "cost=918.40..918.41"
part that you're seeing in the EXPLAIN output.

You could try adding an index that suits all your equality WHERE
clause filters, or some subset of them and put the date column as the
final indexed column and see what happens.

David

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Rob Sargent 2025-05-08 14:04:09 Re: pg_rewind problem: cannot find WAL
Previous Message Justin Clift 2025-05-08 12:28:26 Re: Is anyone up for hosting the online PG game "Schemaverse"?