Re: Statistics Import and Export - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Statistics Import and Export
Date
Msg-id CADkLM=fuZgyuMr=x9p9Bas7coVpSnezpzebU0Dc8HGe_5hodWQ@mail.gmail.com
Whole thread Raw
In response to Re: Statistics Import and Export  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
What is the benefit of a return value from the pg_set_*_stats variants?
As far as I can tell, there is none because they throw an ERROR if
anything goes wrong, so they should just return VOID. What am I
missing?

Probably nothing. The nuances of "this stat didn't get set but these other two did" are too complex for a scalar to report, and pg_set_relation_stats() doesn't do nuance, anyway. I've attached a patch that returns void instead.
 

The return value is more interesting for pg_restore_relation_stats()
and pg_restore_attribute_stats(), which will be used by pg_dump and
which are designed to keep going on non-fatal errors. Isn't that what
this discussion should be about?

Yes. I was trying to focus the conversation on something that could be easily resolved first, and then move on to -restore which is trickier.

Patch that allows relation_statistics_update to continue after one failed stat (0001) attached, along with bool->void change (0002).
 

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Avoiding superfluous buffer locking during nbtree backwards scans
Next
From: Andy Fan
Date:
Subject: Re: Considering fractional paths in Append node