Re: PoC/WIP: Extended statistics on expressions

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

In response to

Responses

Browse pgsql-hackers by date

  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