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 1nCtan-0003gh-AI for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Jan 2022 01:28:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nCtam-00062q-8V for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Jan 2022 01:28:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nCtal-00062f-Vm for pgsql-hackers@lists.postgresql.org; Thu, 27 Jan 2022 01:28:51 +0000 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nCtaf-0007eZ-FX for pgsql-hackers@lists.postgresql.org; Thu, 27 Jan 2022 01:28:51 +0000 Received: by mail-lj1-x230.google.com with SMTP id t14so2014272ljh.8 for ; Wed, 26 Jan 2022 17:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=QUeZg6/mGFwWvy4326ZYNTTHIylPx6WSxFdJfeAF4bg=; b=JTTs5Hs1iSNauIiwJS3jSOpJrvNaekVZwf9vCOw5n7r5pJgN82JCBi0nLZQPfBtdOH FD7u1i0EsnJtGy1XDHGVfMEpQdhNtVDknHsikWNdTWLBtBfAzo2eFUsL2xvUqLdOk2+g FmHVvw5BiMIHBuOWe3nxdIz9fuDiiY7/6P+gfhB/19/YpSQPpdy3HcWbpFtGT81KA3QE XOO8iEAd9nLUEJCLIHL897CQefmmUJGDDZHA/+iWLfXMqaT65MLq7FBxj+knJ7C5UMZW JnMITEZlu47fRWudgKwPtKAKcABC9tdD8D8MEEzk0doVtGJru8dNNVHOmCcb938oy0Yk 3cjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QUeZg6/mGFwWvy4326ZYNTTHIylPx6WSxFdJfeAF4bg=; b=DSIsumZmnNqcAgrL5Ne8M/ebyOlGS3ZK8r6EC2jgy7imBIWfARedD9H03eXY5xtyqy TppEjwn6z6GAEf2xPstS634O7nmUYH30UdofVT4OWtGQ1lMqfzfKrPCLS1jIiuYMLrKS j9UIT8jP1fFoXqSHlhvqZQuN7zqDXd54d6Yhc8A2g/m6gmHj7y/UxddH9kx9yprDDGu/ yQsVRYztrIwI+HYtiWC3/e0TEl9/RqlMgAN6kAt7AZtYXrIbgVagWIcipSMJyO1sZeKe JqXWfCTXk13Mp2n1PemAGE9fu/Rmd1jZ2vRokarwo8UiavBi5+EwCkGdD+ZB73fxLsfT NSlg== X-Gm-Message-State: AOAM532KHKPBpiglN26Ml3Lxn/JIh//ngT6QoYeIS2WXCo9PthNzbrdr zAiX0iWMSM7N8fz3BLdEaMAfOs4Afir+/ZKt5DZDmOZBsFZDh9w= X-Google-Smtp-Source: ABdhPJzZS4zLf4JLhs5UpAF+eU9UtiLaziQ7TemO6Pwu2in7hG8NCr0EwpmM7SeRNaXyV9RtUIJEnTJvRGI8Ck8dmiM= X-Received: by 2002:a2e:a713:: with SMTP id s19mr1283475lje.197.1643246924341; Wed, 26 Jan 2022 17:28:44 -0800 (PST) MIME-Version: 1.0 From: TAO TANG Date: Thu, 27 Jan 2022 09:28:32 +0800 Message-ID: Subject: Question on partition pruning involving stable operator: timestamptz_ge_date To: pgsql-hackers@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000003423f305d6863d44" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003423f305d6863d44 Content-Type: text/plain; charset="UTF-8" Hi, I tested the following case in PostgreSQL master:58e2e6 the partition table created: create table tbl_dts (dts timestamp with time zone not null) partition by range(dts); create table tbl_dts_1 partition of tbl_dts for values from ('2021-07-02') to ('2021-08-01'); create table tbl_dts_2 partition of tbl_dts for values from ('2021-08-02') to ('2021-09-01'); create table tbl_dts_3 partition of tbl_dts for values from ('2021-09-02') to ('2021-10-01'); create table tbl_dts_4 partition of tbl_dts for values from ('2021-10-02') to ('2021-11-01'); and the query: explain select * from tbl_dts where dts between '2022-01-20'::date and '2022-01-26'::date; QUERY PLAN --------------------------------------------- Append (cost=0.00..175.82 rows=44 width=8) Subplans Removed: 4 (2 rows) the plan shows all the partitions are pruned, but in gdb tracing, it shows that the pruning happens in ExecInitAppend, and during planning stage pg does not prune any partitions. this is because in function match_clause_to_partition_key do not handle the case for STABLE operator: if (op_volatile(opno) != PROVOLATILE_IMMUTABLE) { context->has_mutable_op = true; /* * When pruning in the planner, we cannot prune with mutable * operators. */ if (context->target == PARTTARGET_PLANNER) return PARTCLAUSE_UNSUPPORTED; } the procs for timestamptz compare with date are STABLE: proname | provolatile ----------------------+------------- timestamptz_lt_date | s timestamptz_le_date | s timestamptz_eq_date | s timestamptz_gt_date | s timestamptz_ge_date | s timestamptz_ne_date | s timestamptz_cmp_date | s (7 rows) but in ExecInitAppend call perform_pruning_base_step which do not consider the STABLE property of the cmpfn. so I have serveral questions: 1) why in planning the function volatility is considered but not in execInitAppend; 2) why timestamptz_xxx_date is STABLE not IMMUTABLE; thanks. --0000000000003423f305d6863d44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I tested the following c= ase in PostgreSQL master:58e2e6

the partition= table created:

=C2=A0=C2=A0=C2=A0 create= table tbl_dts (dts timestamp with time zone not null) partition by range(d= ts);
=C2=A0=C2=A0=C2=A0 create table tbl_dts_1 partition of tbl_dts for = values from ('2021-07-02') to ('2021-08-01');
=C2=A0=C2= =A0=C2=A0 create table tbl_dts_2 partition of tbl_dts for values from ('= ;2021-08-02') to ('2021-09-01');
=C2=A0=C2=A0=C2=A0 create t= able tbl_dts_3 partition of tbl_dts for values from ('2021-09-02') = to ('2021-10-01');
=C2=A0=C2=A0=C2=A0 create table tbl_dts_4 par= tition of tbl_dts for values from ('2021-10-02') to ('2021-11-0= 1');

and the query:
<= br>
=C2=A0=C2=A0=C2=A0 explain select * from tbl_dts where dts be= tween '2022-01-20'::date and '2022-01-26'::date;
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0 QUERY PLAN =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0
---------------------------------------------
=C2=A0Append =C2=A0= (cost=3D0.00..175.82 rows=3D44 width=3D8)
=C2=A0 =C2=A0Subplans Removed:= 4
(2 rows)

the plan shows all the partitions a= re pruned, but in gdb tracing, it shows that
the pruning hap= pens in ExecInitAppend, and during planning stage pg does not
pru= ne any partitions. this is because in function match_clause_to_partition_ke= y
do not handle the case for STABLE operator:

<= /div>
if (op_volatile(opno) !=3D PROVOLATILE_IMMUTABLE)
{
co= ntext->has_mutable_op =3D true;

/*
* When pruning in th= e planner, we cannot prune with mutable
* operators.
*/
= if (context->target =3D=3D PARTTARGET_PLANNER)
return PARTCLAUSE= _UNSUPPORTED;
}

the procs for timestamptz com= pare with date are STABLE:

=C2=A0 =C2=A0 =C2=A0=C2= =A0 proname =C2=A0 =C2=A0 =C2=A0 =C2=A0| provolatile
------------------= ----+-------------
=C2=A0timestamptz_lt_date =C2=A0| s
=C2=A0timestam= ptz_le_date =C2=A0| s
=C2=A0timestamptz_eq_date =C2=A0| s
=C2=A0times= tamptz_gt_date =C2=A0| s
=C2=A0timestamptz_ge_date =C2=A0| s
=C2=A0ti= mestamptz_ne_date =C2=A0| s
=C2=A0timestamptz_cmp_date | s
(7 rows)

but in ExecInitAppend call perform_pruning_base_ste= p which do not consider the STABLE
property of the cmpfn.

so I have serveral questions:
1) why in plannin= g the function volatility is considered but not in execInitAppend;
2) why timestamptz_xxx_date is STABLE not IMMUTABLE;

thanks.

--0000000000003423f305d6863d44--