From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PoC/WIP: Extended statistics on expressions |
Date: | 2021-09-03 03:56:01 |
Message-ID: | 20210903035601.GT26465@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 01, 2021 at 06:45:29PM +0200, Tomas Vondra wrote:
> However while polishing the second patch, I realized we're allowing
> statistics on expressions referencing system attributes. So this fails;
>
> CREATE STATISTICS s ON ctid, x FROM t;
>
> but this passes:
>
> CREATE STATISTICS s ON (ctid::text), x FROM t;
>
> IMO we should reject such expressions, just like we reject direct references
> to system attributes - patch attached.
Right, same as indexes. +1
> Furthermore, I wonder if we should reject expressions without any Vars? This
> works now:
>
> CREATE STATISTICS s ON (11:text) FROM t;
>
> but it seems rather silly / useless, so maybe we should reject it.
To my surprise, this is also allowed for indexes...
But (maybe this is what I was remembering) it's prohibited to have a constant
expression as a partition key.
Expressions without a var seem like a case where the user did something
deliberately silly, and dis-similar from the case of making a stats expression
on a simple column - that seemed like it could be a legitimate
mistake/confusion (it's not unreasonable to write an extra parenthesis, but
it's strange if that causes it to behave differently).
I think it's not worth too much effort to prohibit this: if they're determined,
they can still write an expresion with a var which is constant. I'm not going
to say it's worth zero effort, though.
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2021-09-03 04:11:16 | Re: suboverflowed subtransactions concurrency performance optimize |
Previous Message | Bharath Rupireddy | 2021-09-03 03:53:02 | Re: improve pg_receivewal code |