On Mon, Feb 12, 2018 at 10:07 AM, Alvaro Herrera
<alvherre@alvh.no-ip.org> wrote:
> The followup question is what to do for multi-table stats objects. I
> think the options are that it should be dumped if:
>
> 1. any of its tables are dumped
> 2. *all* its tables are dumped
> 3. the schema containing the stats object is dumped
>
> I think #2 is a loser: the object goes missing if you dump the tables
> individually.
>
> #3 has a similar problem: if you put the stats object in a schema that's
> not that of any of the involved tables (admittedly a somewhat odd
> choice), then again the stats object goes missing, and there is no
> indication that the dump is incomplete except that the application
> becomes slower -- a situation difficult to detect (unlike missing
> regular objects, because then queries break in obvious ways).
>
> My preference is for #1. It has the small problem that if you have one
> dump for each table, the stats object appears more than once (so
> restoring both causes an error during restore of the second one), but I
> don't think this is terrible.
It's not the worst thing in the world, but it's a long way from being
the best thing. My personal experience has been that it sucks when
you get errors during a restore -- it's often not clear exactly what
object was affected and whether the error is something that's going to
break your application. Of course, it's even worse if you are
restoring in single-transaction or on-error-stop mode.
I believe I previously argued that statistics objects should be
considered first-class objects in their own right, not just table
properties, and that's still my position. In short, I agree with Tom.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company