On Wed, 10 Apr 2024 at 23:51, Tom Lane wrote:
> Is it really necessary for Citus' filter to be a security qual rather
> than a plain ol' filter condition?
No, it's not. I think using security quals simply required the least
amount of code (and it worked just fine if you didn't have lots of
Jelte Fennema-Nio writes:
> On Wed, 10 Apr 2024 at 22:11, Tom Lane wrote:
>> If there's a case you can demonstrate where "\d foo" doesn't optimize
>> into an indexscan, we should look into exactly why that's happening,
>> because I think the cause must be more subtle than this.
> Hmm, okay so I
On Wed, 10 Apr 2024 at 22:11, Tom Lane wrote:
> There may be an argument for psql to do what you suggest,
> but so far it seems like duplicative complication.
>
> If there's a case you can demonstrate where "\d foo" doesn't optimize
> into an indexscan, we should look into exactly why that's
Jelte Fennema-Nio writes:
> On Wed, 10 Apr 2024 at 20:06, Tom Lane wrote:
>> Really? ISTM this argument is ignoring an optimization the backend
>> has understood for a long time.
> Interesting. I didn't know about that optimization. I can't check
> right now, but probably the COLLATE breaks
On Wed, 10 Apr 2024, 23:37 Jelte Fennema-Nio, wrote:
> On Wed, 10 Apr 2024 at 20:21, Kirill Reshke
> wrote:
> > Do we need to force Collaction here like in other branches?
> > if (PQserverVersion(conn) >= 12)
> >appendPQExpBufferStr(buf, " COLLATE pg_catalog.default");
>
> According to
On Wed, 10 Apr 2024 at 20:21, Kirill Reshke wrote:
> Do we need to force Collaction here like in other branches?
> if (PQserverVersion(conn) >= 12)
>appendPQExpBufferStr(buf, " COLLATE pg_catalog.default");
According to the commit and codecomment that introduced the COLLATE,
it was
On Wed, 10 Apr 2024 at 20:06, Tom Lane wrote:
> Really? ISTM this argument is ignoring an optimization the backend
> has understood for a long time.
Interesting. I didn't know about that optimization. I can't check
right now, but probably the COLLATE breaks that optimization.
Hi
> Regex matching is obviously unnecessary when we're looking for an exact
> match. This checks for this (common) case and starts using plain
> equality in that case.
+1
> + appendPQExpBuffer(buf, "(%s OPERATOR(pg_catalog.=) ", namevar);
> + appendStringLiteralConn(buf, [2], conn);
> +
Jelte Fennema-Nio writes:
> Running "\d tablename" from psql could take multiple seconds when
> running on a system with 100k+ tables. The reason for this was that
> a sequence scan on pg_class takes place, due to regex matching being
> used.
> Regex matching is obviously unnecessary when we're
Patch looks good to me. Great idea overall, that forced regex has always
bugged me.
+ char *regexChars = "|*+?()[]{}.^$\\";
One super minor optimization is that we technically do not need to scan for
')' and ']'. If they appear without their partner, the query will fail
anyway. :)
Running "\d tablename" from psql could take multiple seconds when
running on a system with 100k+ tables. The reason for this was that
a sequence scan on pg_class takes place, due to regex matching being
used.
Regex matching is obviously unnecessary when we're looking for an exact
match. This
11 matches
Mail list logo
