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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Is stats update during COPY IN really a good idea?
Date: 2001-05-21 18:07:28
Message-ID: 29614.990468448@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-05-21 18:36:01 Re: AW: [HACKERS] Fix for tablename in targetlist
Previous Message Mikheev, Vadim 2001-05-21 18:01:45 RE: Plans for solving the VACUUM problem