Re: Is stats update during COPY IN really a good idea?

> > You have to VACUUM to get pg_class updated after COPY, right?
> 
> But doing this is only interesting if you need to update reltuples in
> order to get the planner to generate reasonable plans.  In reality, if
> you've added enough data to cause the plans to shift, you probably ought
> to do an ANALYZE anyway to update pg_statistic.  Given that ANALYZE is a
> lot cheaper than it used to be, I think that the notion of making COPY
> do this looks fairly obsolete anyhow.

Yes, but remember, we are trying to catch ignorant cases, not
experienced people.

> > Oh, I see.  Can we disable the pg_class update if we are in a
> > multi-statement transaction?
> 
> Ugh.  Do you really want COPY's behavior to depend on context like that?
> 
> If you did want context-dependent behavior, a saner approach would be to
> only try to update reltuples if the copy has more than, say, doubled the
> old value.  This would be likely to happen in bulk load and unlikely to
> happen in concurrent-insertions-that-choose-to-use-COPY.  But I'm not
> convinced we need it at all.

Maybe not.  The COPY/pg_class hack is just to quiet people who have done
COPY and forgotten VACUUM or ANALYZE.  Maybe the user is only performing
a few operations before deleting the table.  Updating pg_class does help
in that case.


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026