Re: [PATCHES] WAL bypass for CTAS

2005-06-20 Thread Alvaro Herrera
On Mon, Jun 20, 2005 at 09:55:12PM +0100, Simon Riggs wrote: > I put those changes in mainly for COPY. If you don't make any request at > all to FSM then a relation never gets to the MRU relation FSM list. I > agree that it is not strictly necessary, but leaving it off would be a > change in behav

Re: [PATCHES] WAL bypass for CTAS

2005-06-20 Thread Simon Riggs
On Mon, 2005-06-20 at 17:09 -0400, Alvaro Herrera wrote: > On Mon, Jun 20, 2005 at 09:55:12PM +0100, Simon Riggs wrote: > > > I put those changes in mainly for COPY. If you don't make any request at > > all to FSM then a relation never gets to the MRU relation FSM list. I > > agree that it is not

Re: [PATCHES] WAL bypass for CTAS

2005-06-20 Thread Simon Riggs
On Mon, 2005-06-20 at 14:50 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > I enclose a complete patch for avoiding WAL usage for CREATE TABLE AS > > SELECT, when not in archive mode (PITR). The main use case for this is > > large BI environments that create summary tables or p

Re: [PATCHES] WAL bypass for CTAS

2005-06-20 Thread Tom Lane
Simon Riggs <[EMAIL PROTECTED]> writes: > I enclose a complete patch for avoiding WAL usage for CREATE TABLE AS > SELECT, when not in archive mode (PITR). The main use case for this is > large BI environments that create summary tables or prejoined tables, > though there are many general applicatio

Re: [PATCHES] WAL bypass for CTAS

2005-06-20 Thread Bruce Momjian
Tom has applied this patch. Thanks. --- Simon Riggs wrote: > I enclose a complete patch for avoiding WAL usage for CREATE TABLE AS > SELECT, when not in archive mode (PITR). The main use case for this is > large BI environm

Re: [PATCHES] WAL bypass for CTAS

2005-06-05 Thread Simon Riggs
On Sun, 2005-06-05 at 10:20 +1000, Neil Conway wrote: > Bruce Momjian wrote: > > Could we do your NOLOGGING automatically in COPY if we test to see if > > anyone else is connected to our current database? Remember that this patch doe NOT yet handle COPY, but that is planned... > That seems pretty

Re: [PATCHES] WAL bypass for CTAS

2005-06-04 Thread Russell Smith
On Sun, 5 Jun 2005 10:29 am, 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 relea

Re: [PATCHES] WAL bypass for CTAS

2005-06-04 Thread Neil Conway
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,

Re: [PATCHES] WAL bypass for CTAS

2005-06-04 Thread Bruce Momjian
Neil Conway wrote: > Bruce Momjian wrote: > > Could we do your NOLOGGING automatically in COPY if we test to see if > > anyone else is connected to our current database? > > That seems pretty fragile -- what happens if someone connects after the > COPY has started? Considering that many COPY oper

Re: [PATCHES] WAL bypass for CTAS

2005-06-04 Thread Neil Conway
Bruce Momjian wrote: Could we do your NOLOGGING automatically in COPY if we test to see if anyone else is connected to our current database? That seems pretty fragile -- what happens if someone connects after the COPY has started? Considering that many COPY operations can take many minutes or

Re: [PATCHES] WAL bypass for CTAS

2005-06-04 Thread Bruce Momjian
Simon Riggs wrote: > I enclose a complete patch for avoiding WAL usage for CREATE TABLE AS > SELECT, when not in archive mode (PITR). The main use case for this is > large BI environments that create summary tables or prejoined tables, > though there are many general applications. > > There is no