From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18344: Pruning tables partitioned by bool range fails with invalid strategy |
Date: | 2024-02-16 02:56:31 |
Message-ID: | CAApHDvqdnpebVXsxT4BouGFHkCX+4pupr+rxckgkxRprj+kzow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, 16 Feb 2024 at 05:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> What seems to be happening is that gen_prune_step_op is getting
> op_is_ne = true and doing this:
>
> /*
> * For clauses that contain an <> operator, set opstrategy to
> * InvalidStrategy to signal get_matching_list_bounds to do the right
> * thing.
> */
> opstep->opstrategy = op_is_ne ? InvalidStrategy : opstrategy;
>
> but then we're failing in get_matching_range_bounds, ie somebody
> taught get_matching_list_bounds to do the right thing but not
> any of the other code paths.
hmm, yeah. I'm just trying to wrap my head around if this can even
work for RANGE partitioned tables.
> I'm also wondering how we got there in the first place. It looks like
> match_boolean_partition_clause thinks it can translate "b IS NOT true"
> to "b <> true", which is flat wrong --- it gives the wrong result for
> null.
Thought I'd fixed that in e0693faf7, but looks like I only tested it
with DEFAULT partitions, not NULL partitions. A fairly simple fix for
that part:
/* Always include the default partition if any. */
result->scan_default = partition_bound_has_default(boundinfo);
+ /* Likewise for the NULL partition, if any */
+ result->scan_null = partition_bound_accepts_nulls(boundinfo);
I'll look at the RANGE <> bool stuff.
David
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2024-02-16 06:15:54 | BUG #18346: pg restore issue with generated cloumn in Postgres v13.14 |
Previous Message | Tom Lane | 2024-02-15 21:30:39 | Re: BUG #18343: Incorrect description in postgresql.conf for max_parallel_workers_per_gather |