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

From Noah Misch
Subject Re: PoC/WIP: Extended statistics on expressions
Date
Msg-id 20210611045546.GA573364@rfd.leadboat.com
Whole thread Raw
In response to Re: PoC/WIP: Extended statistics on expressions  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: PoC/WIP: Extended statistics on expressions
List pgsql-hackers
On Sun, Jun 06, 2021 at 09:13:17PM +0200, Tomas Vondra wrote:
> 
> On 6/6/21 7:37 AM, Noah Misch wrote:
> > On Sat, Mar 27, 2021 at 01:17:14AM +0100, Tomas Vondra wrote:
> >> OK, pushed after a bit more polishing and testing.
> > 
> > This added a "transformed" field to CreateStatsStmt, but it didn't mention
> > that field in src/backend/nodes.  Should those functions handle the field?
> > 
> 
> Yup, that's a mistake - it should do whatever CREATE INDEX is doing. Not
> sure if it can result in error/failure or just inefficiency (due to
> transforming the expressions repeatedly), but it should do whatever
> CREATE INDEX is doing.
> 
> Thanks for noticing! Fixed by d57ecebd12.

Great.  For future reference, this didn't need a catversion bump.  readfuncs.c
changes need a catversion bump, since the catalogs might contain input for
each read function.  Other src/backend/nodes functions don't face that.  Also,
src/backend/nodes generally process fields in the order that they appear in
the struct.  The order you used in d57ecebd12 is nicer, being more like
IndexStmt, so I'm pushing an order change to the struct.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Question about StartLogicalReplication() error path
Next
From: Noah Misch
Date:
Subject: Re: libpq debug log