On Sun, 21 Jan 2024 at 00:31, Tom Lane wrote:
>
> jian he writes:
> > Now I see your point. If the transformed plan is right, the whole
> > added code should be fine.
> > but keeping the textrange_supp related test should be a good idea.
> > since we don't have SUBTYPE_OPCLASS related sql tests.
jian he writes:
> Now I see your point. If the transformed plan is right, the whole
> added code should be fine.
> but keeping the textrange_supp related test should be a good idea.
> since we don't have SUBTYPE_OPCLASS related sql tests.
Yeah, it's a little harder to make a table-less test for
On Wed, Jan 17, 2024 at 5:46 AM Tom Lane wrote:
>
> But perhaps someone has an argument for a different rule?
>
> Anyway, pending discussion of that point, I think the code is good
> to go. I don't like the test cases much though: they expend many more
> cycles than necessary. You could prove
jian he writes:
> [ v5-0001-Simplify-containment-in-range-constants-with-supp.patch ]
I spent some time reviewing and cleaning up this code. The major
problem I noted was that it doesn't spend any effort thinking about
cases where it'd be unsafe or undesirable to apply the transformation.
In
fix a typo and also did a minor change.
from
+ if (lowerExpr != NULL && upperExpr != NULL)
+ return (Node *) makeBoolExpr(AND_EXPR, list_make2(lowerExpr, upperExpr),
-1);
+ else if (lowerExpr != NULL)
+ return (Node *) lowerExpr;
+ else if (upperExpr != NULL)
+ return (Node *) upperExpr;
to
+
On 12-11-2023 20:20, Laurenz Albe wrote:
On Sun, 2023-11-12 at 18:15 +0100, Laurenz Albe wrote:
I adjusted your patch according to my comments; what do you think?
I have added the patch to the January commitfest, with Jian and Kim as authors.
I hope that is OK with you.
Sounds great to me.
On Sun, 2023-11-12 at 18:15 +0100, Laurenz Albe wrote:
> I adjusted your patch according to my comments; what do you think?
I have added the patch to the January commitfest, with Jian and Kim as authors.
I hope that is OK with you.
Yours,
Laurenz Albe
On Fri, 2023-10-20 at 16:24 +0800, jian he wrote:
> [new patch]
Thanks, that patch works as expected and passes regression tests.
Some comments about the code:
> --- a/src/backend/utils/adt/rangetypes.c
> +++ b/src/backend/utils/adt/rangetypes.c
> @@ -558,7 +570,6 @@
On Fri, Oct 20, 2023 at 12:01 AM Laurenz Albe wrote:
>
> On Fri, 2023-10-13 at 14:26 +0800, jian he wrote:
> > Collation problem seems solved.
>
> I didn't review your patch in detail, there is still a problem
> with my example:
>
> CREATE TYPE textrange AS RANGE (
> SUBTYPE = text,
>
On Fri, 2023-10-13 at 14:26 +0800, jian he wrote:
> Collation problem seems solved.
I didn't review your patch in detail, there is still a problem
with my example:
CREATE TYPE textrange AS RANGE (
SUBTYPE = text,
SUBTYPE_OPCLASS = text_pattern_ops
);
CREATE TABLE tx (t text
On Tue, Aug 1, 2023 at 10:07 AM Laurenz Albe wrote:
> >
> >
> > > I had an idea about this:
> > > So far, you only consider constant ranges. But if we have a STABLE range
> > > expression, you could use an index scan for "expr <@ range", for example
> > > Index Cond (expr >= lower(range) AND
On Sat, 2023-07-08 at 08:11 +0200, Kim Johan Andersson wrote:
> On 07-07-2023 13:20, Laurenz Albe wrote:
> > I wrote:
> > > You implement both "SupportRequestIndexCondition" and
> > > "SupportRequestSimplify",
> > > but when I experimented, the former was never called. That does not
> > >
On 07-07-2023 13:20, Laurenz Albe wrote:
I wrote:
You implement both "SupportRequestIndexCondition" and "SupportRequestSimplify",
but when I experimented, the former was never called. That does not
surprise me, since any expression of the shape "expr <@ range constant"
can be simplified. Is
I wrote:
> You implement both "SupportRequestIndexCondition" and
> "SupportRequestSimplify",
> but when I experimented, the former was never called. That does not
> surprise me, since any expression of the shape "expr <@ range constant"
> can be simplified. Is the "SupportRequestIndexCondition"
> On Sat, 2023-04-29 at 17:07 +0200, Kim Johan Andersson wrote:
> > I had noticed that performance wasn't great when using the @> or <@
> > operators when examining if an element is contained in a range.
> > Based on the discussion in [1] I would like to suggest the following
> > changes:
> >
>
On Sat, 2023-04-29 at 17:07 +0200, Kim Johan Andersson wrote:
> I had noticed that performance wasn't great when using the @> or <@
> operators when examining if an element is contained in a range.
> Based on the discussion in [1] I would like to suggest the following
> changes:
>
> This patch
Any thoughts on this change?
17 matches
Mail list logo
