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 17:54:24 |
Message-ID: | 29501.990467664@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:
> People are using COPY into the same table at the same time?
Yes --- we had a message from someone who was doing that (and running
into unrelated performance issues) just last week.
> 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?
The reason this is a significant issue is that the first COPY could be
inside a transaction, in which case the lock will persist until that
transaction commits, which could be awhile.
> 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.
No, we cannot; requiring COPY to happen outside a transaction block is
not acceptable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-05-21 17:56:35 | Re: Detecting readline in configure |
Previous Message | Mikheev, Vadim | 2001-05-21 17:52:28 | RE: Plans for solving the VACUUM problem |