> > 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
> > 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
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2001-05-22 11:53:31|
|Subject: Re: AW: Is stats update during COPY IN really a good idea?|
|Previous:||From: Bruce Momjian||Date: 2001-05-22 11:31:18|
|Subject: Re: Re: [GENERAL] Queries across multiple databases ?(was:
SELECT from a table in another database).|