Re: PoC/WIP: Extended statistics on expressions - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: PoC/WIP: Extended statistics on expressions
Date
Msg-id 04b100f9-201b-0bc8-c613-0f918451b599@enterprisedb.com
Whole thread Raw
In response to Re: PoC/WIP: Extended statistics on expressions  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: PoC/WIP: Extended statistics on expressions (\d in old client)
Re: PoC/WIP: Extended statistics on expressions
List 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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: PoC/WIP: Extended statistics on expressions
Next
From: Heikki Linnakangas
Date:
Subject: Re: PoC Refactor AM analyse API