Re: PoC/WIP: Extended statistics on expressions
От | Justin Pryzby |
---|---|
Тема | Re: PoC/WIP: Extended statistics on expressions |
Дата | |
Msg-id | 20210903035601.GT26465@telsasoft.com обсуждение исходный текст |
Ответ на | Re: PoC/WIP: Extended statistics on expressions (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: PoC/WIP: Extended statistics on expressions
|
Список | 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
В списке pgsql-hackers по дате отправления: