pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedAssert failure in CTE inlining with view and correlated subquery
8+ messages / 3 participants
[nested] [flat]
Commits from this thread:
2022-04-21 92e7a53752 eade0043ca e6440d5007 da22ef388a Remove inadequate assertion check in CTE inlining.
* Assert failure in CTE inlining with view and correlated subquery
@ 2022-04-20 21:33 Tomas Vondra <tomas.vondra@enterprisedb.com>
2022-04-21 07:28 ` Re: Assert failure in CTE inlining with view and correlated subquery Richard Guo <guofenglinux@gmail.com>
2022-04-21 07:51 ` Re: Assert failure in CTE inlining with view and correlated subquery Richard Guo <guofenglinux@gmail.com>
0 siblings, 2 replies; 8+ messages in thread
From: Tomas Vondra @ 2022-04-20 21:33 UTC (permalink / raw)
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Hi,
it seems there's something wrong with CTE inlining when there's a view
containing a correlated subquery referencing the CTE. Consider a simple
example like this:
create table results (
id serial primary key,
run text,
tps float4
);
create view results_agg as
with base_tps as (
select run, tps from results
)
select
run,
count(*) as runs,
(select tps from base_tps b where b.run = r.run) AS base_tps
from results r
group by
run
order by
run;
explain SELECT run FROM results_agg ORDER BY 1;
This crashes on this assert in inline_cte():
Assert(context.refcount == 0);
because the refcount value remains 1. There's a backtrace attached.
I don't know why exactly this happens, my knowledge of CTE inlining is
somewhat limited. The counter is clearly out of sync
but a couple more observations:
1) it fails all the way back to PG12, where CTE inlining was added
2) it does not happen if the CTE is defined as MATERIALIZED
QUERY PLAN
-----------------------------------------
Subquery Scan on results_agg
-> Sort
Sort Key: r.run
CTE base_tps
-> Seq Scan on results
-> HashAggregate
Group Key: r.run
-> Seq Scan on results r
(8 rows)
3) without asserts, it seems to work and the query generates this plan
QUERY PLAN
-----------------------------------------
Subquery Scan on results_agg
-> Sort
Sort Key: r.run
-> HashAggregate
Group Key: r.run
-> Seq Scan on results r
(6 rows)
4) it does not seem to happen without the view, i.e. this works
explain
with base_tps as (
select run, tps from results
)
select run from (
select
run,
count(*) as runs,
(select tps from base_tps b where b.run = r.run) AS base_tps
from results r
group by
run
order by
run
) results_agg order by 1;
The difference between plans in (2) and (3) is interesting, because it
seems the CTE got inlined, so why was the refcount not decremented?
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
test.sql (application/sql, 710B) download
backtrace.txt (text/plain, 3.0K) download
Missing separate debuginfos, use: dnf debuginfo-install libgcc-11.2.1-9.fc34.x86_64
(gdb) bt
#0 0x00007159d9be82a2 in raise () from /lib64/libc.so.6
#1 0x00007159d9bd18a4 in abort () from /lib64/libc.so.6
#2 0x000000000096d3fa in ExceptionalCondition (conditionName=conditionName@entry=0xae4ed3 "context.refcount == 0", errorType=errorType@entry=0x9c3017 "FailedAssertion", fileName=fileName@entry=0xae4da6 "subselect.c", lineNumber=lineNumber@entry=1166) at assert.c:69
#3 0x000000000078acda in inline_cte (cte=0x134e240, root=0x1242298) at subselect.c:1166
#4 SS_process_ctes (root=root@entry=0x1242298) at subselect.c:963
#5 0x0000000000782fb1 in subquery_planner (glob=0x134dbc0, parse=parse@entry=0x134daa8, parent_root=parent_root@entry=0x13491e8, hasRecursion=hasRecursion@entry=false, tuple_fraction=0) at planner.c:650
#6 0x0000000000752afe in set_subquery_pathlist (rte=<optimized out>, rti=<optimized out>, rel=<optimized out>, root=<optimized out>) at allpaths.c:2572
#7 set_rel_size (root=<optimized out>, rel=<optimized out>, rti=<optimized out>, rte=<optimized out>) at allpaths.c:424
#8 0x0000000000755080 in set_base_rel_sizes (root=<optimized out>) at allpaths.c:325
#9 make_one_rel (root=root@entry=0x13491e8, joinlist=joinlist@entry=0x134e078) at allpaths.c:187
#10 0x000000000077b4c2 in query_planner (root=root@entry=0x13491e8, qp_callback=qp_callback@entry=0x77c450 <standard_qp_callback>, qp_extra=qp_extra@entry=0x7fff5a500ba0) at planmain.c:276
#11 0x0000000000781122 in grouping_planner (root=<optimized out>, tuple_fraction=<optimized out>) at planner.c:1467
#12 0x00000000007838a1 in subquery_planner (glob=glob@entry=0x134dbc0, parse=parse@entry=0x1241818, parent_root=parent_root@entry=0x0, hasRecursion=hasRecursion@entry=false, tuple_fraction=tuple_fraction@entry=0) at planner.c:1044
#13 0x0000000000783ee3 in standard_planner (parse=0x1241818, query_string=<optimized out>, cursorOptions=2048, boundParams=<optimized out>) at planner.c:406
#14 0x000000000084e7a8 in pg_plan_query (querytree=0x1241818, query_string=query_string@entry=0x12407d0 "SELECT run FROM results_agg ORDER BY 1;", cursorOptions=cursorOptions@entry=2048, boundParams=boundParams@entry=0x0) at postgres.c:883
#15 0x000000000084e8a1 in pg_plan_queries (querytrees=0x134bf00, query_string=query_string@entry=0x12407d0 "SELECT run FROM results_agg ORDER BY 1;", cursorOptions=cursorOptions@entry=2048, boundParams=boundParams@entry=0x0) at postgres.c:975
#16 0x000000000084ebab in exec_simple_query (query_string=0x12407d0 "SELECT run FROM results_agg ORDER BY 1;") at postgres.c:1169
#17 0x00000000008506df in PostgresMain (dbname=<optimized out>, username=<optimized out>) at postgres.c:4542
#18 0x00000000007c1d12 in BackendRun (port=0x1265e90, port=0x1265e90) at postmaster.c:4491
#19 BackendStartup (port=0x1265e90) at postmaster.c:4219
#20 ServerLoop () at postmaster.c:1793
#21 0x00000000007c2c20 in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x123a3b0) at postmaster.c:1465
#22 0x0000000000510725 in main (argc=3, argv=0x123a3b0) at main.c:202
* Re: Assert failure in CTE inlining with view and correlated subquery
2022-04-20 21:33 Assert failure in CTE inlining with view and correlated subquery Tomas Vondra <tomas.vondra@enterprisedb.com>
@ 2022-04-21 07:28 ` Richard Guo <guofenglinux@gmail.com>
1 sibling, 0 replies; 8+ messages in thread
From: Richard Guo @ 2022-04-21 07:28 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Thu, Apr 21, 2022 at 5:33 AM Tomas Vondra <tomas.vondra@enterprisedb.com>
wrote:
>
> The difference between plans in (2) and (3) is interesting, because it
> seems the CTE got inlined, so why was the refcount not decremented?
>
The query is not actually referencing the cte. So the cte range table
entry would not appear anywhere in the query tree. That's why refcount
is not decremented after inline cte walker.
If we explicitly reference the cte in the query, say in the targetlist,
it would then work.
# explain (costs off) SELECT * FROM results_agg ORDER BY 1;
QUERY PLAN
---------------------------------------
Sort
Sort Key: r.run
-> HashAggregate
Group Key: r.run
-> Seq Scan on results r
SubPlan 1
-> Seq Scan on results
Filter: (run = r.run)
(8 rows)
IMO the culprit is that we incorrectly set cterefcount to one while
actually the cte is not referenced at all.
Thanks
Richard
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Assert failure in CTE inlining with view and correlated subquery
2022-04-20 21:33 Assert failure in CTE inlining with view and correlated subquery Tomas Vondra <tomas.vondra@enterprisedb.com>
@ 2022-04-21 07:51 ` Richard Guo <guofenglinux@gmail.com>
2022-04-21 08:29 ` Re: Assert failure in CTE inlining with view and correlated subquery Richard Guo <guofenglinux@gmail.com>
1 sibling, 1 reply; 8+ messages in thread
From: Richard Guo @ 2022-04-21 07:51 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Thu, Apr 21, 2022 at 5:33 AM Tomas Vondra <tomas.vondra@enterprisedb.com>
wrote:
>
> it seems there's something wrong with CTE inlining when there's a view
> containing a correlated subquery referencing the CTE.
>
BTW, seems view is not a necessary condition to reproduce this issue.
For instance:
create table t (a int, b int);
explain (costs off) select a from
(
with t_cte as (select a, b from t)
select
a,
(select b from t_cte where t_cte.a = t.a) AS t_sub
from t
) sub;
Thanks
Richard
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Assert failure in CTE inlining with view and correlated subquery
2022-04-20 21:33 Assert failure in CTE inlining with view and correlated subquery Tomas Vondra <tomas.vondra@enterprisedb.com>
2022-04-21 07:51 ` Re: Assert failure in CTE inlining with view and correlated subquery Richard Guo <guofenglinux@gmail.com>
@ 2022-04-21 08:29 ` Richard Guo <guofenglinux@gmail.com>
2022-04-21 11:48 ` Re: Assert failure in CTE inlining with view and correlated subquery Tomas Vondra <tomas.vondra@enterprisedb.com>
0 siblings, 1 reply; 8+ messages in thread
From: Richard Guo @ 2022-04-21 08:29 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Thu, Apr 21, 2022 at 3:51 PM Richard Guo <guofenglinux@gmail.com> wrote:
>
> On Thu, Apr 21, 2022 at 5:33 AM Tomas Vondra <
> tomas.vondra@enterprisedb.com> wrote:
>
>>
>> it seems there's something wrong with CTE inlining when there's a view
>> containing a correlated subquery referencing the CTE.
>>
>
> BTW, seems view is not a necessary condition to reproduce this issue.
> For instance:
>
> create table t (a int, b int);
>
> explain (costs off) select a from
> (
> with t_cte as (select a, b from t)
> select
> a,
> (select b from t_cte where t_cte.a = t.a) AS t_sub
> from t
> ) sub;
>
Further debugging shows that in this repro the reference to the CTE is
removed when generating paths for the subquery 'sub', where we would try
to remove subquery targetlist items that are not needed. So for the
items we are to remove, maybe we need to check if they contain CTEs and
if so decrease cterefcount of the CTEs correspondingly.
Thanks
Richard
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Assert failure in CTE inlining with view and correlated subquery
2022-04-20 21:33 Assert failure in CTE inlining with view and correlated subquery Tomas Vondra <tomas.vondra@enterprisedb.com>
2022-04-21 07:51 ` Re: Assert failure in CTE inlining with view and correlated subquery Richard Guo <guofenglinux@gmail.com>
2022-04-21 08:29 ` Re: Assert failure in CTE inlining with view and correlated subquery Richard Guo <guofenglinux@gmail.com>
@ 2022-04-21 11:48 ` Tomas Vondra <tomas.vondra@enterprisedb.com>
2022-04-21 19:03 ` Re: Assert failure in CTE inlining with view and correlated subquery Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 8+ messages in thread
From: Tomas Vondra @ 2022-04-21 11:48 UTC (permalink / raw)
To: Richard Guo <guofenglinux@gmail.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 4/21/22 10:29, Richard Guo wrote:
>
> On Thu, Apr 21, 2022 at 3:51 PM Richard Guo <guofenglinux@gmail.com
> <mailto:guofenglinux@gmail.com>> wrote:
>
>
> On Thu, Apr 21, 2022 at 5:33 AM Tomas Vondra
> <tomas.vondra@enterprisedb.com
> <mailto:tomas.vondra@enterprisedb.com>> wrote:
>
>
> it seems there's something wrong with CTE inlining when there's
> a view
> containing a correlated subquery referencing the CTE.
>
>
> BTW, seems view is not a necessary condition to reproduce this issue.
> For instance:
>
> create table t (a int, b int);
>
> explain (costs off) select a from
> (
> with t_cte as (select a, b from t)
> select
> a,
> (select b from t_cte where t_cte.a = t.a) AS t_sub
> from t
> ) sub;
>
>
> Further debugging shows that in this repro the reference to the CTE is
> removed when generating paths for the subquery 'sub', where we would try
> to remove subquery targetlist items that are not needed. So for the
> items we are to remove, maybe we need to check if they contain CTEs and
> if so decrease cterefcount of the CTEs correspondingly.
>
Right, at some point we remove the unnecessary targetlist entries, but
that ignores the entry may reference a CTE. That's pretty much what I
meant by the counter being "out of sync".
Updating the counter while removing the entry is one option, but maybe
we could simply delay counting the CTE references until after that?
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Assert failure in CTE inlining with view and correlated subquery
2022-04-20 21:33 Assert failure in CTE inlining with view and correlated subquery Tomas Vondra <tomas.vondra@enterprisedb.com>
2022-04-21 07:51 ` Re: Assert failure in CTE inlining with view and correlated subquery Richard Guo <guofenglinux@gmail.com>
2022-04-21 08:29 ` Re: Assert failure in CTE inlining with view and correlated subquery Richard Guo <guofenglinux@gmail.com>
2022-04-21 11:48 ` Re: Assert failure in CTE inlining with view and correlated subquery Tomas Vondra <tomas.vondra@enterprisedb.com>
@ 2022-04-21 19:03 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-04-21 20:45 ` Re: Assert failure in CTE inlining with view and correlated subquery Tomas Vondra <tomas.vondra@enterprisedb.com>
0 siblings, 1 reply; 8+ messages in thread
From: Tom Lane @ 2022-04-21 19:03 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: Richard Guo <guofenglinux@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> On 4/21/22 10:29, Richard Guo wrote:
>> Further debugging shows that in this repro the reference to the CTE is
>> removed when generating paths for the subquery 'sub', where we would try
>> to remove subquery targetlist items that are not needed. So for the
>> items we are to remove, maybe we need to check if they contain CTEs and
>> if so decrease cterefcount of the CTEs correspondingly.
> Right, at some point we remove the unnecessary targetlist entries, but
> that ignores the entry may reference a CTE. That's pretty much what I
> meant by the counter being "out of sync".
> Updating the counter while removing the entry is one option, but maybe
> we could simply delay counting the CTE references until after that?
I think we should just drop this cross-check altogether; it is not nearly
useful enough to justify the work that'd be involved in maintaining
cterefcount accurately for all such transformations. All it's really
there for is to be sure that we don't need to make a subplan for the
inlined CTE.
There are two downstream consumers of cte_plan_ids, which currently just
have Asserts that we made a subplan. I think it'd be worth converting
those to real run-time tests, which leads me to something more or less as
attached.
regards, tom lane
Attachments:
remove-bogus-assertion-about-cte-refcount.patch (text/x-diff, 3.1K) download
diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
index 998212dda8..d84f66a81b 100644
--- a/src/backend/optimizer/path/allpaths.c
+++ b/src/backend/optimizer/path/allpaths.c
@@ -2804,7 +2804,8 @@ set_cte_pathlist(PlannerInfo *root, RelOptInfo *rel, RangeTblEntry *rte)
if (ndx >= list_length(cteroot->cte_plan_ids))
elog(ERROR, "could not find plan for CTE \"%s\"", rte->ctename);
plan_id = list_nth_int(cteroot->cte_plan_ids, ndx);
- Assert(plan_id > 0);
+ if (plan_id <= 0)
+ elog(ERROR, "no plan was made for CTE \"%s\"", rte->ctename);
cteplan = (Plan *) list_nth(root->glob->subplans, plan_id - 1);
/* Mark rel with estimated output rows, width, etc */
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c
index 95476ada0b..7905bc4654 100644
--- a/src/backend/optimizer/plan/createplan.c
+++ b/src/backend/optimizer/plan/createplan.c
@@ -3898,7 +3898,8 @@ create_ctescan_plan(PlannerInfo *root, Path *best_path,
if (ndx >= list_length(cteroot->cte_plan_ids))
elog(ERROR, "could not find plan for CTE \"%s\"", rte->ctename);
plan_id = list_nth_int(cteroot->cte_plan_ids, ndx);
- Assert(plan_id > 0);
+ if (plan_id <= 0)
+ elog(ERROR, "no plan was made for CTE \"%s\"", rte->ctename);
foreach(lc, cteroot->init_plans)
{
ctesplan = (SubPlan *) lfirst(lc);
diff --git a/src/backend/optimizer/plan/subselect.c b/src/backend/optimizer/plan/subselect.c
index 863e0e24a1..df4ca12919 100644
--- a/src/backend/optimizer/plan/subselect.c
+++ b/src/backend/optimizer/plan/subselect.c
@@ -61,7 +61,6 @@ typedef struct inline_cte_walker_context
{
const char *ctename; /* name and relative level of target CTE */
int levelsup;
- int refcount; /* number of remaining references */
Query *ctequery; /* query to substitute */
} inline_cte_walker_context;
@@ -1157,13 +1156,9 @@ inline_cte(PlannerInfo *root, CommonTableExpr *cte)
context.ctename = cte->ctename;
/* Start at levelsup = -1 because we'll immediately increment it */
context.levelsup = -1;
- context.refcount = cte->cterefcount;
context.ctequery = castNode(Query, cte->ctequery);
(void) inline_cte_walker((Node *) root->parse, &context);
-
- /* Assert we replaced all references */
- Assert(context.refcount == 0);
}
static bool
@@ -1226,9 +1221,6 @@ inline_cte_walker(Node *node, inline_cte_walker_context *context)
rte->coltypes = NIL;
rte->coltypmods = NIL;
rte->colcollations = NIL;
-
- /* Count the number of replacements we've done */
- context->refcount--;
}
return false;
diff --git a/src/include/nodes/pathnodes.h b/src/include/nodes/pathnodes.h
index c5ab53e05c..244d1e1197 100644
--- a/src/include/nodes/pathnodes.h
+++ b/src/include/nodes/pathnodes.h
@@ -241,7 +241,8 @@ struct PlannerInfo
List *init_plans; /* init SubPlans for query */
- List *cte_plan_ids; /* per-CTE-item list of subplan IDs */
+ List *cte_plan_ids; /* per-CTE-item list of subplan IDs (or -1 if
+ * no subplan was made for that CTE) */
List *multiexpr_params; /* List of Lists of Params for MULTIEXPR
* subquery outputs */
* Re: Assert failure in CTE inlining with view and correlated subquery
2022-04-20 21:33 Assert failure in CTE inlining with view and correlated subquery Tomas Vondra <tomas.vondra@enterprisedb.com>
2022-04-21 07:51 ` Re: Assert failure in CTE inlining with view and correlated subquery Richard Guo <guofenglinux@gmail.com>
2022-04-21 08:29 ` Re: Assert failure in CTE inlining with view and correlated subquery Richard Guo <guofenglinux@gmail.com>
2022-04-21 11:48 ` Re: Assert failure in CTE inlining with view and correlated subquery Tomas Vondra <tomas.vondra@enterprisedb.com>
2022-04-21 19:03 ` Re: Assert failure in CTE inlining with view and correlated subquery Tom Lane <tgl@sss.pgh.pa.us>
@ 2022-04-21 20:45 ` Tomas Vondra <tomas.vondra@enterprisedb.com>
2022-04-21 21:59 ` Re: Assert failure in CTE inlining with view and correlated subquery Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 8+ messages in thread
From: Tomas Vondra @ 2022-04-21 20:45 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Richard Guo <guofenglinux@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 4/21/22 21:03, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>> On 4/21/22 10:29, Richard Guo wrote:
>>> Further debugging shows that in this repro the reference to the CTE is
>>> removed when generating paths for the subquery 'sub', where we would try
>>> to remove subquery targetlist items that are not needed. So for the
>>> items we are to remove, maybe we need to check if they contain CTEs and
>>> if so decrease cterefcount of the CTEs correspondingly.
>
>> Right, at some point we remove the unnecessary targetlist entries, but
>> that ignores the entry may reference a CTE. That's pretty much what I
>> meant by the counter being "out of sync".
>> Updating the counter while removing the entry is one option, but maybe
>> we could simply delay counting the CTE references until after that?
>
> I think we should just drop this cross-check altogether; it is not nearly
> useful enough to justify the work that'd be involved in maintaining
> cterefcount accurately for all such transformations. All it's really
> there for is to be sure that we don't need to make a subplan for the
> inlined CTE.
>
> There are two downstream consumers of cte_plan_ids, which currently just
> have Asserts that we made a subplan. I think it'd be worth converting
> those to real run-time tests, which leads me to something more or less as
> attached.
>
WFM. I'm not particularly attached to the assert, so if you say it's not
worth it let's get rid of it.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Assert failure in CTE inlining with view and correlated subquery
2022-04-20 21:33 Assert failure in CTE inlining with view and correlated subquery Tomas Vondra <tomas.vondra@enterprisedb.com>
2022-04-21 07:51 ` Re: Assert failure in CTE inlining with view and correlated subquery Richard Guo <guofenglinux@gmail.com>
2022-04-21 08:29 ` Re: Assert failure in CTE inlining with view and correlated subquery Richard Guo <guofenglinux@gmail.com>
2022-04-21 11:48 ` Re: Assert failure in CTE inlining with view and correlated subquery Tomas Vondra <tomas.vondra@enterprisedb.com>
2022-04-21 19:03 ` Re: Assert failure in CTE inlining with view and correlated subquery Tom Lane <tgl@sss.pgh.pa.us>
2022-04-21 20:45 ` Re: Assert failure in CTE inlining with view and correlated subquery Tomas Vondra <tomas.vondra@enterprisedb.com>
@ 2022-04-21 21:59 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 8+ messages in thread
From: Tom Lane @ 2022-04-21 21:59 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: Richard Guo <guofenglinux@gmail.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> On 4/21/22 21:03, Tom Lane wrote:
>> I think we should just drop this cross-check altogether; it is not nearly
>> useful enough to justify the work that'd be involved in maintaining
>> cterefcount accurately for all such transformations. All it's really
>> there for is to be sure that we don't need to make a subplan for the
>> inlined CTE.
> WFM. I'm not particularly attached to the assert, so if you say it's not
> worth it let's get rid of it.
Done.
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2022-04-21 21:59 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-04-20 21:33 Assert failure in CTE inlining with view and correlated subquery Tomas Vondra <tomas.vondra@enterprisedb.com>
2022-04-21 07:28 ` Richard Guo <guofenglinux@gmail.com>
2022-04-21 07:51 ` Richard Guo <guofenglinux@gmail.com>
2022-04-21 08:29 ` Richard Guo <guofenglinux@gmail.com>
2022-04-21 11:48 ` Tomas Vondra <tomas.vondra@enterprisedb.com>
2022-04-21 19:03 ` Tom Lane <tgl@sss.pgh.pa.us>
2022-04-21 20:45 ` Tomas Vondra <tomas.vondra@enterprisedb.com>
2022-04-21 21:59 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox