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 1sjRtP-000oG7-MO for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Aug 2024 23:15:59 +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 1sjRtN-00BrPW-LU for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Aug 2024 23:15:58 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sjRtN-00BrNE-80 for pgsql-hackers@lists.postgresql.org; Wed, 28 Aug 2024 23:15:57 +0000 Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sjRtK-001vAM-P1 for pgsql-hackers@postgresql.org; Wed, 28 Aug 2024 23:15:56 +0000 Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-7141feed424so55345b3a.2 for ; Wed, 28 Aug 2024 16:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20230601.gappssmtp.com; s=20230601; t=1724886953; x=1725491753; darn=postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=ZF538ifE0BezMUOVwWqj1jD/qo1LaIhV+LkjLaJgjIw=; b=OKL2S5Bv+BNvH5P7JxzfeAN1XRYrF/fG1xgkbxDbXsBWNe6+XKFdJ74+W6cVjFSulO V1wu+urwNYtQlgbTPHDZveaOjVMkaH5Y3jrG92PZSpqpAWAnEJJJZumz4e+D3c1Ji0+N OWSn4wgFRsbQHySXOSchOiqJccBiCrgBmk/2Zn61dyWRjcBGgG7q+tXtOAe9oqYactfA nly/EZT2rnJp1wmuOnNKMJeV3qyS5bhkfqF8qKg77BKQotTYxrWsG+pioQ9DtPG4/sC8 PUhdScCUKJM8xOU16LkIddmofiD8t9DEciQ86QMSsnURXpD1gU4Dq3GVbhKHiXRUwllm hMLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724886953; x=1725491753; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ZF538ifE0BezMUOVwWqj1jD/qo1LaIhV+LkjLaJgjIw=; b=qC/1moAXG30zsiYeVTr2KILDrD30tgKqOXu8OG2MSJa2A5xhZESGwteG31ut1pZDDO zcvMJpTHprRXszJ17bOY/NAinVgIvCfT+n63qOnypOJey9l9gY5d+SeJ6yUy5jKB11H1 FDNOeOA/2XFHJU3k31ix6/WViwC4ekxHEd6k4kl7b1k1GeB5+i1KqngaOhcxoJrubzyl 5Cx8l0c0QTO313IDbamUc2VgihagtG7XUSzA0a3wwWgmjd+IU+NLGmR0TqUYSAnk5g5P /CTf3YUjof1WpI1x1ra3ukhY+27H7AfBZKaZTXdffTz5rRttoozm5UTBVJQeC99HuSG1 /q/A== X-Gm-Message-State: AOJu0Yx2hCNbtlfu9yl305FU/87JkGiKttd5ZlzSpkZMebPoEgeNubT7 wRVDm6TUu5a+EQFMkyL/zn24A4GwJ8ciizgla758wrEjpDHuVDAADG/Il10GfQ== X-Google-Smtp-Source: AGHT+IGyFBk4gwXlpUZnvwlfNRFYtQMOcbgld7aCHRzccyG0yIjRaW3L3IoudZjs7NcCGHiwpY/0eA== X-Received: by 2002:a05:6a00:803:b0:70d:2a88:a483 with SMTP id d2e1a72fcca58-715df9cf352mr1457801b3a.0.1724886953311; Wed, 28 Aug 2024 16:15:53 -0700 (PDT) Received: from [172.18.11.17] ([12.126.244.130]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-715e569ececsm1894b3a.124.2024.08.28.16.15.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Aug 2024 16:15:52 -0700 (PDT) Message-ID: <646c3d09475e49a5d1145c91af0ce3fdc3cdee96.camel@j-davis.com> Subject: Re: allowing extensions to control planner behavior From: Jeff Davis To: Robert Haas Cc: "pgsql-hackers@postgresql.org" Date: Wed, 28 Aug 2024 16:15:51 -0700 In-Reply-To: References: <95e423ea042a8d2f85c76ee28feb7a5b10265f4d.camel@j-davis.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, 2024-08-28 at 16:35 -0400, Robert Haas wrote: > On Wed, Aug 28, 2024 at 4:29=E2=80=AFPM Jeff Davis wr= ote: > > Preserving a path for the right amount of time seems like the > > primary > > challenge for most of the use cases you raised (removing paths is > > easier than resurrecting one that was pruned too early). If we try > > to > > keep a path around, that implies that we need to keep parent paths > > around too, which leads to an explosion if we aren't careful. > >=20 > > But we already solved all of that for pathkeys. We keep the paths > > around if there's a reason to (a useful pathkey) and there's not > > some > > other cheaper path that also satisfies the same reason. >=20 > But we've already solved it for this case, too. This is exactly what > incrementing disabled_nodes does. Hints are often described as something positive: use this index, use a hash join here, etc. Trying to force a positive thing by adding negative attributes to everything else is awkward. We've all had the experience where we disable one plan type hoping for a good plan, and we end up getting a different crazy plan that we didn't expect, and need to disable a few more plan types. Beyond awkwardness, one case where it matters is the interaction between an extension that provides hints and an extension that offers a CustomScan. How is the hints extension supposed to disable a path it doesn't know about? Regards, Jeff Davis