Re: [PATCHES] WAL bypass for CTAS

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] WAL bypass for CTAS

Bruce Momjian-2
Neil Conway wrote:
> Bruce Momjian wrote:
> > Well, it isn't going to help us for 8.1 because 8.0 will not have it,
> > and if we add the clause we make loading the data into previous releases
> > harder.
>
> pg_dump output in general is not compatible with prior releases. It
> would be a nice feature to have, but until we have it, I don't see that
> changing or not changing the COPY syntax will make a major difference to
> dump backward compatibility.

Right, usually the schema changes are not backward compatibible, but the
COPY commands are.  But now that I look at this example:

        COPY test (x) FROM stdin;
        1
        \.

The column name "(x)" actually broke backward compatibility when we
added it, so yea, we could add a new option now too.  No one complained
when we added the column names, so another option would be fine.

I suppose no one would like adding an option to turn off locking during
COPY, so the non-WAL logging would become the default?  (Just asking.
You know me, I like automatic.)

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  [hidden email]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
Reply | Threaded
Open this post in threaded view
|

Re: [PATCHES] WAL bypass for CTAS

Tom Lane-2
Bruce Momjian <[hidden email]> writes:
> I suppose no one would like adding an option to turn off locking during
> COPY, so the non-WAL logging would become the default?

When and if we add LOCK or some equivalent option to COPY, I'm sure
we'll change pg_dump to specify that option in its output.  But trying
to get that behavior by default for existing dumps seems to me to be
far more dangerous than it's worth.  Not every performance improvement
has to automatically apply to existing dumps...

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [hidden email]