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

> We have a TODO item
> * Update reltuples in COPY
>
> I was just about to go do this when I realized that it may not be such
> a hot idea after all. The problem is that updating pg_class.reltuples
> means that concurrent COPY operations will block each other, because
> they want to update the same row in pg_class. You can already see this
> happen in CREATE INDEX:

People are using COPY into the same table at the same time?

> While this doesn't bother me for CREATE INDEX, it does bother me for
> COPY, since people often use COPY to avoid per-tuple INSERT overhead.
> It seems pretty likely that this will cause blocking problems for real
> applications. I think that may be a bigger problem than the benefit of
> not needing a VACUUM (or, now, ANALYZE) to get the stats updated.

Oh, well we can either decide to do it or remove the TODO item. Either
way we win!

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? Can't we just
start a new transaction and update the pg_class row, that way we don't
have to open it for writing during the copy.

FYI, I had a 100k deep directory that caused me problems this morning.
Just catching up.

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