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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026