Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uD1XM-005U8p-Gy for pgsql-general@arkaria.postgresql.org; Thu, 08 May 2025 13:43:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uD1XL-003OY7-DY for pgsql-general@arkaria.postgresql.org; Thu, 08 May 2025 13:43:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uD1XL-003OXz-2t for pgsql-general@lists.postgresql.org; Thu, 08 May 2025 13:43:43 +0000 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uD1XI-000puq-1A for pgsql-general@lists.postgresql.org; Thu, 08 May 2025 13:43:42 +0000 Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-5499614d3d2so1304694e87.3 for ; Thu, 08 May 2025 06:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746711819; x=1747316619; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BFqE9fWkKDgL/XbVICF0PzhfoofJGJBTSUPDRWxh12c=; b=RVvoWE5NGfpTYjmUGxpDmW3M3IUa0CNT/jnZ4RN4k53bCwXl1pI63KtAIKOGSMcfie jCOnVuesWZp5MGEztuNqRuu+Ochqp2WqGryIoMyQYOuvQw1gG9TTKGXjCAf6YWqRQAIG Dtk903/G9KjQZsWAN5TP5i1DOpTUL9SBhGNvf1mfJ07nPEOoPVVIWmf9T/g6ljD1PvNe 3IOF0/ttdMWPwUNWjiSR8hPPuAOfexuZf679klIYvgQy5wO0qu0LBc9Enh3rVtbNK7n4 tYj4o1HtkKq43S5qAj6gjQt7jSWrTPlj1xJNTC2WnHj85XBK2wmrFQlSYJwT+6O/NH6Z /Zjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746711819; x=1747316619; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BFqE9fWkKDgL/XbVICF0PzhfoofJGJBTSUPDRWxh12c=; b=K/Cbah+kv3JfqDnElyIaHTvYcDCIJyiZEmsZp8W94vzK6fK4alGeusTOz07RWeFA41 rl7WOfE3f8K+xUv7skpK+el9CEoAN1o0/eJ/W/Ub8wNl23tZTwoPZUhk3yuW/ijjzJ+C VDgUl56nOa5b0c3Mmr9Jcm/4xQyqx3c/b2J/u+RdacJ2IA37Xe7laBOhD6i24G8/SWJc bIkfolI2CWnBL+yGghWvdtPW+1Oeu5i26a/ZEyDpLrw818R3l8xHJ4WSJAw5UnWlH9yW 7o+ecoT+uTSf0VilwOBH40U+2aDsbP/sZMzxocuiqfhd4GV3sqBaROxWLcEHplJ1U73k Fn3A== X-Gm-Message-State: AOJu0YzRmmvMYk3L/SWs3erMAnhrBF2QFaunrZqrwqYA3NCt2eL6LIBr RVc2h6+NDNBqhsivSUhmLGwJr94JKrxumbzBOh/Pb5FNRe2iKJXDiU95eJJ9bA16VYzSAG1MFdE y6q9gzBXsubvTaIhLYNdhrrGz+lYG7NHB X-Gm-Gg: ASbGncsaJB1bLWkr/OzbbIQOPqWMl2kkViz6Ib3g6s9adYkXa/wxa8sgT5olICDDS7O yeiuxRzGyLXRVxCbe5PoWMr/L+GefxfuS+aVA8ni17P2QzAyUy+l7F0m78zdmgUx1cP5wkiUMUy X9HHIUo1VbUlaaALtfeLmfG6tIpSM4w2QqBuSYpoQUJXiPR+raJGOcbUWB X-Google-Smtp-Source: AGHT+IHKgqBGfcQDE6zJKwh2vOkpLSkiAI8dRGcR3roFwj3O4T0qSISJ7Y7AFeA5aPD/Tp/QrSpUrTYyXasuPUad4cE= X-Received: by 2002:a05:6512:401e:b0:54e:86f3:5e57 with SMTP id 2adb3069b0e04-54fbfbec16dmr1337049e87.3.1746711818679; Thu, 08 May 2025 06:43:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Rowley Date: Fri, 9 May 2025 01:43:27 +1200 X-Gm-Features: ATxdqUH2F2-hzFVXoX2wFfIcTRsrwivE31aKEjxMW69NzITQJijfDe5YXZcx-Fc Message-ID: Subject: Re: Feature-Request: Performance-Optimization when using limit in combination with order by on querys using union To: Karsten P Cc: pgsql-general@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 8 May 2025 at 22:57, Karsten P 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