On Thu, 8 May 2025 at 22:57, Karsten P <mr.mister...@hotmail.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
