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

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> My vote is to update pg_class.  The VACUUM takes much more time than the
> update, and we are only updating the pg_class row, right?
>> 
>> What?  What does VACUUM have to do with this?

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

> 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.
        regards, tom lane