| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp> |
| Subject: | Re: Remove xmin and cmin from frozen tuples |
| Date: | 2005-09-02 20:44:53 |
| Message-ID: | 20050902204453.GK29066@surnet.cl |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Sep 02, 2005 at 04:27:59PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> >> Contrariwise, it doesn't really matter (I think) if there are WAL-logged
> >> records already in the table and COPY is adding more that aren't logged.
>
> > Only if the page is locked in a fashion that the bulk loader can't
> > insert tuples into a page that the other transaction is using.
>
> What other transaction? The point I was making is that
> BEGIN;
> CREATE TABLE ...
> INSERT ...
> COPY ...
> is still optimizable. There isn't going to be anyone competing with
> the COPY while it runs.
Sure. I was thinking that you were looking for a mechanism to relax the
other restriction.
--
Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com
Dios hizo a Adán, pero fue Eva quien lo hizo hombre.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2005-09-02 20:48:39 | Re: Remove xmin and cmin from frozen tuples |
| Previous Message | Josh Berkus | 2005-09-02 20:35:42 | Re: Remove xmin and cmin from frozen tuples |