[EMAIL PROTECTED] wrote:
Are you planning to add XMLAGG() support? And if so, will it work
basically the same (from the user's perspective) as the XMLAGG()
syntax in Nikolay's patch?
The XMLAGG in Nikolay's patch didn't work right, so I removed it. If
someone wants to clean it up, please
s/XMLGEN/XMLAGG/
Sorry, I meant XMLAGG() not XMLGEN()
And now that I have the name right, I found the answer:
http://archives.postgresql.org/pgsql-hackers/2006-12/msg01022.php
Sorry to be a bother...
-- Korry
On Fri, 2007-01-05 at 22:57 -0500, Tom Lane wrote:
Jim Nasby [EMAIL PROTECTED] writes:
On Jan 5, 2007, at 6:30 AM, Zeugswetter Andreas ADI SD wrote:
Ok, so when you need CRC's on a replicate (but not on the master) you
Which sounds to me like a good reason to allow the option in
FYI, I am going need to add documentation in the COPY manual page or no
one will know about this performance enhancement.
---
Simon Riggs wrote:
http://archives.postgresql.org/pgsql-hackers/2006-10/msg01172.php
As
On Sat, 2007-01-06 at 11:05 -0500, Bruce Momjian wrote:
FYI, I am going need to add documentation in the COPY manual page or no
one will know about this performance enhancement.
I have some questions:
As discussed on -hackers, its possible to avoid writing any WAL at all
for COPY in these
Joshua D. Drake wrote:
On Sat, 2007-01-06 at 11:05 -0500, Bruce Momjian wrote:
FYI, I am going need to add documentation in the COPY manual page or no
one will know about this performance enhancement.
I have some questions:
As discussed on -hackers, its possible to avoid writing any
BEGIN;
CREATE TABLE foo...
INSERT INTO foo VALUES ('1');
COPY foo...
COMMIT;
On ABORT, the entire table disappears, as well as the INSERT, so I don't
see any problem. I assume the INSERT is WAL logged.
No I don't see any problems, I am just trying to understand the
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, I am going need to add documentation in the COPY manual page or no
one will know about this performance enhancement.
I don't think it belongs in COPY. What would make more sense is another
item under the populating a database performance tips,
Simon Riggs wrote:
As discussed on -hackers, its possible to avoid writing any WAL at all
for COPY in these circumstances:
Cool.
The enclosed patch implements this, as discussed. There is no user
interface to enable/disable, just as with CTAS and CREATE INDEX; no
docs, just code comments.
On Sat, 2007-01-06 at 16:41 -0200, Euler Taveira de Oliveira wrote:
Simon Riggs wrote:
As discussed on -hackers, its possible to avoid writing any WAL at all
for COPY in these circumstances:
Cool.
The enclosed patch implements this, as discussed. There is no user
interface to
Euler Taveira de Oliveira [EMAIL PROTECTED] writes:
Simon Riggs wrote:
The enclosed patch implements this, as discussed. There is no user
interface to enable/disable, just as with CTAS and CREATE INDEX; no
docs, just code comments.
IMHO, this deserves an GUC parameter (use_wal_in_copy?).
Patch applied. Thanks.
---
Euler Taveira de Oliveira wrote:
Peter Eisentraut wrote:
On the name of the option, it's not actually a data directory, so I'd
just
call it --xlogdir, parallel to --datadir.
Seems
Joshua D. Drake wrote:
BEGIN;
CREATE TABLE foo...
INSERT INTO foo VALUES ('1');
COPY foo...
COMMIT;
On ABORT, the entire table disappears, as well as the INSERT, so I don't
see any problem. I assume the INSERT is WAL logged.
No I don't see any problems, I
Simon Riggs wrote:
Somehow, neither of these statements seem likely to be uttered by
a sane DBA ...
If I take a backup of a server and bring it up on a new system, the
blocks in the backup will not have been CRC checked before they go to
disk.
If I take the same server and now stream
On Sat, 2007-01-06 at 15:24 -0500, Bruce Momjian wrote:
Joshua D. Drake wrote:
BEGIN;
CREATE TABLE foo...
INSERT INTO foo VALUES ('1');
COPY foo...
COMMIT;
On ABORT, the entire table disappears, as well as the INSERT, so I don't
see any problem. I
Simon Riggs wrote:
Or in other words, does this patch mean that all COPY execution that is
within a transaction will ignore WAL?
Yes, because it is possible to do in all cases.
Very happy to add documentation where Tom suggested.
Reason for no documentation was that CREATE INDEX
Joshua D. Drake wrote:
IMHO, this deserves an GUC parameter (use_wal_in_copy?). Because a lot
of people use COPY because it's faster than INSERT but expects that it
will be in WAL. The default would be use_wal_in_copy = true.
That I don't think makes sense. A copy is an all or nothing
Dhanaraj M wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Dhanaraj M wrote:
I am sending the patch for the following TODO item:
Allow the identifier length to be increased via a configure option
You should use pg_config.h, not mangle
On Saturday 06 January 2007 16:40, Bruce Momjian wrote:
Simon Riggs wrote:
Or in other words, does this patch mean that all COPY execution that
is within a transaction will ignore WAL?
Yes, because it is possible to do in all cases.
Very happy to add documentation where Tom
On Saturday 06 January 2007 16:36, Simon Riggs wrote:
The rule is: if the relfilenode for a table is new in this transaction
(and therefore the whole things will be dropped at end-of-transaction)
then *all* COPY commands are able to avoid writing WAL safely, if:
- PITR is not enabled
- there
Tom Lane wrote:
I'm wondering how this got into the TODO list. It seems rather
pointless, and likely to create client compatibility problems (if
not, why is NAMEDATALEN exported at all?)
I think because it used to be used in libpq's notification structure.
--
Peter Eisentraut
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
... why is NAMEDATALEN exported at all?)
I think because it used to be used in libpq's notification structure.
Yeah, you're probably right. Maybe we should take it out of
postgres_ext.h and move it to pg_config_manual.h. If no one
Simon Riggs [EMAIL PROTECTED] writes:
The rule is: if the relfilenode for a table is new in this transaction
(and therefore the whole things will be dropped at end-of-transaction)
then *all* COPY commands are able to avoid writing WAL safely, if:
- PITR is not enabled
- there is no active
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Reason for no documentation was that CREATE INDEX and CREATE TABLE AS
SELECT already use this optimisation, but to my knowledge neither was/is
documented on those command pages.
I wasn't aware those used the optimization. Seems they
Robert Treat [EMAIL PROTECTED] writes:
On Saturday 06 January 2007 16:36, Simon Riggs wrote:
snip
BEGIN;
CREATE TABLE foo...
INSERT INTO foo --uses WAL
COPY foo.. --no WAL
INSERT INTO foo --uses WAL
COPY foo.. --no WAL
INSERT INTO foo --uses WAL
COPY foo... --no WAL
Is there some technical reason that the INSERT statements need to use WAL
in
these scenarios?
First, there's enough other overhead to an INSERT that you'd not save
much percentagewise. Second, not using WAL doesn't come for free: the
cost is having to fsync the whole table
On Sat, 2007-01-06 at 22:09 -0500, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
cost is having to fsync the whole table afterwards. So it really only
makes sense for commands that one can expect are writing pretty much
all of the table. I could easily see it being a net loss
The attached patch warns users when they create documentation output
that has no index, and suggests re-running 'gmake'.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index:
Bruce Momjian [EMAIL PROTECTED] writes:
The attached patch warns users when they create documentation output
that has no index, and suggests re-running 'gmake'.
This is just useless noise. If it could tell the difference between an
up-to-date index and a not-up-to-date one, there might be some
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The attached patch warns users when they create documentation output
that has no index, and suggests re-running 'gmake'.
This is just useless noise. If it could tell the difference between an
up-to-date index and a not-up-to-date
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The attached patch warns users when they create documentation output
that has no index, and suggests re-running 'gmake'.
This is just useless noise. If it could tell the difference between an
up-to-date
On Sat, 2007-01-06 at 23:38 -0500, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The attached patch warns users when they create documentation output
that has no index, and suggests re-running 'gmake'.
This is just useless noise. If it could tell the difference between an
Joshua D. Drake wrote:
On Sat, 2007-01-06 at 23:38 -0500, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The attached patch warns users when they create documentation output
that has no index, and suggests re-running 'gmake'.
This is just useless noise. If it could tell the
33 matches
Mail list logo
