> > 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
