Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nh1Z6-00022B-IU for pgsql-admin@arkaria.postgresql.org; Wed, 20 Apr 2022 04:03:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nh1Z5-0005CX-2r for pgsql-admin@arkaria.postgresql.org; Wed, 20 Apr 2022 04:03:39 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nh1Z4-0005CN-OW for pgsql-admin@lists.postgresql.org; Wed, 20 Apr 2022 04:03:38 +0000 Received: from mail-yb1-xb29.google.com ([2607:f8b0:4864:20::b29]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nh1Yy-00044J-8N for pgsql-admin@lists.postgresql.org; Wed, 20 Apr 2022 04:03:37 +0000 Received: by mail-yb1-xb29.google.com with SMTP id x39so676377ybd.8 for ; Tue, 19 Apr 2022 21:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bcqx6FjNr5hhJCPztiNOcDjswLyOAwk72e7n969HYbQ=; b=Fa0J5Emqhx5Ghem50PZTa4dNGlIwVhzZ1ynwEhORsa0+Zhl8g5oByQX6ZHR/16KDBl NPkIRoDKs8ZO1vgl6r0uqC143d2Bketsuu3RZ0PTchx2d1TxTvDvCMRx9Nnf+cVB+k24 xTPCivhXfLPGN0FH3YHRgl/eAkg7KCCsBc8de7aHYgECN10kI2qUJrnjvRER3hzLpqCS 76VikrDQZbOoTRRHI5h9/xn/Ms5pxRZxbOrY9XIJvwnFAjCpjSMgmPhs4+78Vg7+j8Qt JR8odpOdjZoFHIkqtiywBSpSWMpFsbAKArUSBKUZ/kOmwnNE4cfSOqibtX92+JeBgNeY CDog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bcqx6FjNr5hhJCPztiNOcDjswLyOAwk72e7n969HYbQ=; b=A81rtepu54+R5MOu8gj7UdzeZBervEVsSd99rWN8jlZfHlePRWmRWxiwUYnDeXVwOx hNZO9PKwiU33i3kKktE2gDfzCYhT5C30TKj7+2tiFnqZJwuOSMhq0PXSYFfONvKuO0+1 d9ymVi++niTR2T+VVFwsH/8agDci2hwI7hzjXZn5RzklI0SCechYiC+eJxEyhgNVbRhZ LV24tXsRmvFvL3MwXEhch50CuIt8SzGt0fSJLYQeRC9hjtigmMOkw+DNYiwKWGw53D2b jThR6LuIfhdUkVxfyZKTAOKZKDI+uMH4US+slVzPly4K14ieLKukXg/Yts4lrNtK0BTw rluQ== X-Gm-Message-State: AOAM530C4sCk5ReDDAlAVu3yxijZj8jeRGNcX2jLTts46VYuy9SSPaYP 8Uq/z/MpL1xBTEpoUgKfWf+hiFbPkx9N9ui+TuSLIBDLVA== X-Google-Smtp-Source: ABdhPJx5iL5PGOIFLL102CPGCU+ZvlqauyY+deSTBIVe7v0BzELXqC/iTsw3MWpSBMe/pNPFWbKvPt/+gjMtgm+HqmE= X-Received: by 2002:a5b:247:0:b0:624:4d24:94ee with SMTP id g7-20020a5b0247000000b006244d2494eemr17810540ybp.197.1650427411453; Tue, 19 Apr 2022 21:03:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeff Janes Date: Wed, 20 Apr 2022 00:03:20 -0400 Message-ID: Subject: Re: PG Query Planner To: Kenny Bachman Cc: Gaurav Anand , Pgsql-admin Content-Type: multipart/alternative; boundary="00000000000096594f05dd0e1394" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000096594f05dd0e1394 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 19, 2022 at 1:57 PM Kenny Bachman wrote: > Hello, > > My query is : > > SELECT subs.id AS id1_109, > scriber_id AS subs_109 > FROM subscription subs > LEFT OUTER JOIN offer offer1 > ON subs.offer_id = offer1.id > WHERE offer1.is_external_lifecycle_management = FALSE > AND subs.job_next_process_time < '2022-04-19 09:25:25.535' > AND subs.job_in_progress = FALSE > ORDER BY subs.id ASC LIMIT 1 ; > An easy (if you can control the queries) way to force the faster plan is to prohibit it from using using the index to fulfill the ORDER BY, by changing it to "ORDER BY subs.id+0 ASC LIMIT 1" As for getting the planner to get a better plan on its own, I don't think there is much hope. The difference between 0 rows with is_external_lifecycle_management=FALSE, and 1 row meeting that, is the smallest possible difference. Yet still the ratio between them is infinite. Changing a histogram bin count or adding a multivariate statistic is not going to change that. Maybe the executor should be smart enough to cut off the nested loop once it sees the Materialize will never return a row. But that is not a change you can make in user-land. Cheers, Jeff > --00000000000096594f05dd0e1394 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 19, 2022 at 1:57 PM Kenny Bac= hman <kenny.bachman17@gmail= .com> wrote:
Hello,

My query is :

SELECT subs.id AS id1_109,
scriber_id AS subs_109
FRO= M subscription subs
LEFT OUTER JOIN offer offer1
ON subs.offer_id = =3D offer1.id
WHERE = offer1.is_external_lifecycle_management =3D FALSE
AND subs.job_next_pro= cess_time < '2022-04-19 09:25:25.535'
AND subs.job_in_progre= ss =3D FALSE
ORDER BY subs.= id ASC LIMIT 1 ;

An eas= y (if you can control the queries) way to force the faster plan is to prohi= bit it from using using the index to fulfill the ORDER BY, by changing it t= o "ORDER BY=C2=A0subs.id+0=C2=A0ASC LIM= IT 1"

As for getting the planner to get a bet= ter plan on its own, I don't think there is much hope.=C2=A0 The differ= ence between 0 rows with is_external_lifecycle_management=3DFALSE, and 1 ro= w meeting that, is the smallest possible difference. Yet still the ratio be= tween them is infinite.=C2=A0 Changing a histogram bin count or adding a mu= ltivariate statistic is not going to change that.

= Maybe the executor should be smart enough to cut off the nested loop once i= t sees the=C2=A0Materialize will never r= eturn a row.=C2=A0 But that is not a change you can make in user-land.

Cheers,

Jeff
--00000000000096594f05dd0e1394--