From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(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-01-22 13:09:04 |
Message-ID: | 04b100f9-201b-0bc8-c613-0f918451b599@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/22/21 5:01 AM, Justin Pryzby wrote:
> On Fri, Jan 22, 2021 at 04:49:51AM +0100, Tomas Vondra wrote:
>>>> | Statistics objects:
>>>> | "public"."s2" (ndistinct, dependencies, mcv) ON FROM t
>>
>> Umm, for me that prints:
>
>> "public"."s2" ON ((i + 1)), (((i + 1) + 0)) FROM t
>>
>> which I think is OK. But maybe there's something else to trigger the
>> problem?
>
> Oh. It's because I was using /usr/bin/psql and not ./src/bin/psql.
> I think it's considered ok if old client's \d commands don't work on new
> server, but it's not clear to me if it's ok if they misbehave. It's almost
> better it made an ERROR.
>
Well, how would the server know to throw an error? We can't quite patch
the old psql (if we could, we could just tweak the query).
> In any case, why are there so many parentheses ?
>
That's a bug in pg_get_statisticsobj_worker, probably. It shouldn't be
adding extra parentheses, on top of what deparse_expression_pretty does.
Will fix.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2021-01-22 13:12:13 | Re: PoC Refactor AM analyse API |
Previous Message | Tomas Vondra | 2021-01-22 13:06:51 | Re: PoC/WIP: Extended statistics on expressions |