Personally I don't think that it is a good idea to do that.
People will tend to corrupt their systems because they want speed
(sometimes without thinking about the consequences).
I can only think of one scenario where nologging would actually make
sense: Many people use session tables to keep
I have simplified the code according to the discussion. Now there is no pipe
or signaling threads, process access shared memory directly to pass signals.
Seems everything works fine except pg_ctl. I now have two choices to fix it:
(1) Record Shared memory name (it is already there) and the offset
hi
I want to know that does ODBC executes all statement
as simple query as i have't found any thing as
parse/bind/execute messeges in ODBC case.Or where can
i find the implementation of these messeges on ODBC
side
Thx
Zahid K
__
Do you Yahoo!?
On Jun 1, 2005, at 1:42 PM, Michael Glaesemann wrote:
-- v8.0.3
test=# select '25 hours'::interval;
interval
1 day 01:00:00
(1 row)
-- new interval code
test=# select '25 hours'::interval;
interval
--
25:00:00
(1 row)
I'll be digging into the spec later and post
On T, 2005-05-31 at 14:41 -0300, Marc G. Fournier wrote:
Just want to make sure that this is, in fact, what is expected:
client1: begin;
client1: update articles set some_col = foo where id = bar;
client2: update articles set some_col2 = foo2 where id = bar;
client1: update articles set
On T, 2005-05-31 at 17:08 +1200, Mark Kirkwood wrote:
Luke Lonergan wrote:
Tom,
This is a story that is evolving. Anyone else use StorageReview? Great
comprehensive drive benchmarks:
http://www.storagereview.com/
Check the comparisons between 15K RPM SCSI drives and the 2004
Hi,
i want to know how postgres will store a
relation in pages and where can i see the code related
to this in the source code.Plz help me .
S.Nithin
__
Discover Yahoo!
Use Yahoo! to plan a weekend, have fun online and more. Check
On Tue, 2005-05-31 at 11:13 -0400, Tom Lane wrote:
Barnali [EMAIL PROTECTED] writes:
I was wondering whether it will be useful to extend postgreSQL support
to ddl triggers.
This has been proposed and rejected before ... see the archives.
Could we keep track of NOT TODO items also?
The
On Tue, 2005-05-31 at 22:47 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Recent test results have shown a substantial performance improvement
(+25%) if WAL logging is disabled for large COPY statements.
How much of that is left after we fix the 64-bit-CRC issue?
Well, I
Neil Conway [EMAIL PROTECTED] writes:
On Wed, 2005-06-01 at 00:40 -0400, Alvaro Herrera wrote:
This doesn't work for COPY, but maybe for CREATE TABLE AS we could log
the fact that the command was executed, so the replayer could execute
the same command again.
Of course, this
There are some other arguments in favour of a LOAD command Alon?
We already have LOAD, so you'll have to choose something else :)
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
On Tue, 2005-05-31 at 22:31 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
If a table is created as WITHOUT OIDS, is it still possible to take
advantage of the physical tlist optimization?
Um ... it depends. There are cases where you have to have an OID,
and cases where you
Nithin Sontineni wrote:
Hi,
i want to know how postgres will store a
relation in pages and where can i see the code related
to this in the source code.Plz help me .
S.Nithin
__
Discover Yahoo!
Use Yahoo! to plan a weekend, have
Greg Stark [EMAIL PROTECTED] writes:
For CREATE TABLE AS in the non-PITR case you don't really need to WAL log the
records at all. If it fails in the middle you just drop the table. When it
completes you do a checkpoint before acknowledging the COMMIT.
I think this is already done for
On Tue, 2005-05-31 at 22:36 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Hmmm. I seem to recall asking myself why xl_prev existed if it wasn't
used, but passed that by. Damn.
I couldn't believe it'd been overlooked this long, either. It's the
sort of thing that you assume
I have simplified the code according to the discussion. Now
there is no pipe or signaling threads, process access shared
memory directly to pass signals.
Seems everything works fine except pg_ctl. I now have two
choices to fix it:
(1) Record Shared memory name (it is already there) and
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 31 May 2005 17:27
To: Greg Stark
Cc: Mark Cave-Ayland (External); 'Manfred Koizar'; 'Bruce
Momjian'; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
(cut)
The odds of an
On K, 2005-06-01 at 09:16 +0100, Simon Riggs wrote:
On Tue, 2005-05-31 at 22:47 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Recent test results have shown a substantial performance improvement
(+25%) if WAL logging is disabled for large COPY statements.
How much of
The problem I see with this proposal is that the buffer manager knows
how to handle only a equally-sized pages. And the shared memory stuff
gets sized according to size * num_pages. So what happens if a certain
tablespace A with pagesize=X gets to have a lot of its pages cached,
evicting
Date: Tue, 31 May 2005 16:26:20 -0400
From: Tom Lane [EMAIL PROTECTED]
To: pgsql-hackers@postgreSQL.org
Subject: Quick-and-dirty compression for WAL backup blocks
Message-ID: [EMAIL PROTECTED]
(cut)
... make the WAL writing logic aware of the layout
of buffer pages --- specifically, to
On Wed, 2005-06-01 at 16:34 +0800, Christopher Kings-Lynne wrote:
There are some other arguments in favour of a LOAD command Alon?
We already have LOAD, so you'll have to choose something else :)
Its annoying, I grant you. :-)
LOAD 'library' would still need to be the default.
LOAD
On 6/1/05, Zeugswetter Andreas DAZ SD [EMAIL PROTECTED] wrote:
You could create a separate bufferpool per page size. Of course that
has other disadvantages.
Is it really so difficult to create and attach another shmem segment ?
Well, I don't think it is much different from having two
On Wed, 2005-06-01 at 04:44 -0400, Greg Stark wrote:
Greg Stark [EMAIL PROTECTED] writes:
For CREATE TABLE AS in the non-PITR case you don't really need to WAL log
the
records at all. If it fails in the middle you just drop the table. When it
completes you do a checkpoint before
On K, 2005-06-01 at 00:01 +0100, Simon Riggs wrote:
Recent test results have shown a substantial performance improvement
(+25%) if WAL logging is disabled for large COPY statements. This is to
be expected, though has a price attached: losing the ability to crash
recover data loaded in this
On K, 2005-06-01 at 14:00 +0200, Dawid Kuroczko wrote:
On 6/1/05, Zeugswetter Andreas DAZ SD [EMAIL PROTECTED] wrote:
You could create a separate bufferpool per page size. Of course that
has other disadvantages.
Is it really so difficult to create and attach another shmem segment ?
On Wed, 1 Jun 2005, Oleg Bartunov wrote:
We'd love to start tomorrow working on GiST, but we have some current
obligations we need to sort out.
It will probably take more then a day to do fund raising, which is what
Christopher is suggesting ... but they need some sort of 'value' for a
goal
Josh Berkus wrote:
Bruce,
Added to TODO:
* Add the features of packages
o Make private objects accessable only to objects in the same
schema
o Allow current_schema.objname to access current schema objects
o Add session variables
o
[EMAIL PROTECTED] (Jeffrey W. Baker) wrote:
On Mon, 2005-05-30 at 21:38 -0700, Luke Lonergan wrote:
After reading this very comprehensive benchmark:
http://print.tweakers.net/?reviews/557
I purchased one of the Areca controllers with a large battery-backed
cache. It is unholy fast. I
On Wed, 1 Jun 2005, Marc G. Fournier wrote:
On Wed, 1 Jun 2005, Oleg Bartunov wrote:
We'd love to start tomorrow working on GiST, but we have some current
obligations we need to sort out.
It will probably take more then a day to do fund raising, which is what
Christopher is suggesting ...
Simon Riggs wrote:
On Wed, 2005-06-01 at 04:44 -0400, Greg Stark wrote:
Greg Stark [EMAIL PROTECTED] writes:
For CREATE TABLE AS in the non-PITR case you don't really need to WAL log
the
records at all. If it fails in the middle you just drop the table. When it
completes you do
Simon Riggs [EMAIL PROTECTED] writes:
Where I'm leading to is this: If the physical tlist optimization is a
considerable gain, and it required OIDs, then changing the system
default to WITHOUT OIDS will cause us to lose the optimization. Yes?
It doesn't require OIDs, though. What it requires
Greg Stark [EMAIL PROTECTED] writes:
Sorry to followup to my own message, but it occurs to me that COPY could be
made to automatically do this for the case of an empty destination table too.
Not unless you are proposing to change COPY to acquire a lock strong
enough to lock out other writers to
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2005-06-01 at 16:34 +0800, Christopher Kings-Lynne wrote:
There are some other arguments in favour of a LOAD command Alon?
We already have LOAD, so you'll have to choose something else :)
Its annoying, I grant you. :-)
LOAD 'library' would
Simon Riggs [EMAIL PROTECTED] writes:
If I/O is a problem, then surely you will agree that PreAllocXLog is
still required and should not be run by a backend?
It is still required, but it isn't run by backends --- it's fired off
during checkpoints. I think there was some discussion recently
Mark Cave-Ayland [EMAIL PROTECTED] writes:
I'm still a little nervous about dropping down to CRC32 from CRC64 and so
was just wondering what the net saving would be using one CRC64 across the
whole WAL record?
None to speak of; the startup/teardown time is trivial. It's the
per-byte cost that
On 01 Jun 2005 04:44:24 -0400, Greg Stark wrote:
Greg Stark writes:
For CREATE TABLE AS in the non-PITR case you don't really need to WAL log the
records at all. If it fails in the middle you just drop the table. When it
completes you do a checkpoint before acknowledging the COMMIT.
I
Mark Cave-Ayland [EMAIL PROTECTED] writes:
I also noticed your comment above that mentioned that compression would be
less effective as the pages became more full. Would changing the loading
factor of database pages have an effect here, as I would have thought that
the WAL would be fsync'd
Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Sorry to followup to my own message, but it occurs to me that COPY could be
made to automatically do this for the case of an empty destination table
too.
Not unless you are proposing to change COPY to acquire a lock strong
enough to
Jochem van Dieten wrote:
On 01 Jun 2005 04:44:24 -0400, Greg Stark wrote:
Greg Stark writes:
For CREATE TABLE AS in the non-PITR case you don't really need to WAL log
the
records at all. If it fails in the middle you just drop the table. When it
completes you do a checkpoint before
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Not unless you are proposing to change COPY to acquire a lock strong
enough to lock out other writers to the table for the duration ...
Well, if the table is initally empty, what harm is there in locking the
table?
You cannot
On Wed, Jun 01, 2005 at 10:12:34AM -0400, Tom Lane wrote:
Mark Cave-Ayland [EMAIL PROTECTED] writes:
I also noticed your comment above that mentioned that compression would be
less effective as the pages became more full. Would changing the loading
factor of database pages have an effect
Title: fdatasync failed, I/O error
Our customer is running Postgresql v. 7.3.4 on Linux(Redhat 3.0 Ent.)
The application crashed and I am trying to understand what could have caused this kind of problems:
fdatasync of log file 0, segment 2 failed: input/output error
PGSTAT: Error
Michael Glaesemann [EMAIL PROTECTED] writes:
On Jun 1, 2005, at 1:42 PM, Michael Glaesemann wrote:
-- v8.0.3
test=# select '25 hours'::interval;
interval
1 day 01:00:00
(1 row)
-- new interval code
test=# select '25 hours'::interval;
interval
--
25:00:00
(1
Michael Glaesemann [EMAIL PROTECTED] writes:
I've started working on this change, and one difference has shown up
immediately in the regression tests. v8.0.3 currently returns:
SELECT INTERVAL '10 years -11 month -12 days +13:14' AS 9 years...;
9 years...
Magnus Hagander [EMAIL PROTECTED] writes:
Why not just use the pid in teh name, and have one segment per backend?
Being used only for signals you mean? That might work.
I dislike fooling around with the contents of postmaster.pid, as that
will inject platform-specific code into places where
Zahid Khan [EMAIL PROTECTED] writes:
I want to know that does ODBC executes all statement
as simple query as i have't found any thing as
parse/bind/execute messeges in ODBC case.
Probably; the ODBC code long predates the V3 protocol, and I don't think
it's been updated. But you're asking the
Could we keep track of NOT TODO items also?
The question is where do you put this idea if you reject it? :-)
And of course a link to the thread, or an explanation on why it was
rejected. That way if someone can solve the reason for reject it maybe
a new discussion can be made.
--
regards,
In case nobody has seen this:
http://code.google.com/summerofcode.html
Might be something to help fun, say, the GiST stuff? Just need to find a
student that could be mentor'd/directed/brought up to speed?
Marc G. Fournier Hub.Org Networking Services
On 6/1/05, Hans-Jürgen Schönig [EMAIL PROTECTED] wrote:
Personally I don't think that it is a good idea to do that.
People will tend to corrupt their systems because they want speed
(sometimes without thinking about the consequences).
I can only think of one scenario where nologging would
Brusser, Michael [EMAIL PROTECTED] writes:
Our customer is running Postgresql v. 7.3.4 on Linux(Redhat 3.0 Ent.)
The application crashed and I am trying to understand what could have caused
this kind of problems:
fdatasync of log file 0, segment 2 failed: input/output error
PGSTAT:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
Nithin Sontineni wrote:
i want to know how postgres will store a
relation in pages and where can i see the code related
to this in the source code.Plz help me .
You can find the code in src/backend/storage.
Also, read the
On Wed, Jun 01, 2005 at 10:27:04AM -0400, Brusser, Michael wrote:
Our customer is running Postgresql v. 7.3.4 on Linux(Redhat 3.0 Ent.)
The application crashed and I am trying to understand what could have caused
this kind of problems:
fdatasync of log file 0, segment 2 failed:
Marc,
If you wanted to submit PostgreSQL to Google for this, I'd be willing to
work with any potentials. Should someone choose to work on PostgreSQL
projects, the money can go to the group.
If anyone sees a problem with submitting under the PostgreSQL Global
Development Group, I can do it
On Wed, 2005-06-01 at 10:18 -0400, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Not unless you are proposing to change COPY to acquire a lock strong
enough to lock out other writers to the table for the duration ...
Well, if the table is initally empty,
Hannu Krosing [EMAIL PROTECTED] writes:
I think this should be a decision done when creating a table, just like
TEMP tables. So you always know if a certain table is or is not
safe/replicated/recoverable.
This has also the advantage of requiring no changes to actual COPY and
INSERT commands.
Bruce Momjian pgman@candle.pha.pa.us writes:
Jochem van Dieten wrote:
Why only on an empty table? What is the problem with bypassing WAL on
any table as long as all files of that table are fsync'ed before
commit?
Because adding rows to a table might modify existing pages, and if the
COPY
Simon Riggs [EMAIL PROTECTED] writes:
4. Optionally, we set a flag on the table showing the whole table is
frozen. Anybody writing to this table subsequently will spoil this flag.
If the flag is set, all forms of VACUUM will return success immediately
without performing a scan (since it is
On 6/1/05, Bruce Momjian wrote:
Jochem van Dieten wrote:
Why only on an empty table? What is the problem with bypassing WAL on
any table as long as all files of that table are fsync'ed before
commit?
Because adding rows to a table might modify existing pages, and if the
COPY fails, you
Why not just use the pid in teh name, and have one segment
per backend?
Being used only for signals you mean? That might work.
That was my idea. We'll end up using three global namespace objects
(mutex+event+shared memory) instead of one (named pipe), but as we're
not talking thousands
On Wed, 2005-06-01 at 11:31 -0400, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
I think this should be a decision done when creating a table, just like
TEMP tables. So you always know if a certain table is or is not
safe/replicated/recoverable.
This has also the advantage of
On Wed, Jun 01, 2005 at 06:00:28PM +0100, Simon Riggs wrote:
On Wed, 2005-06-01 at 11:31 -0400, Tom Lane wrote:
Perhaps it could work to use an ALTER TABLE command to flip the state.
But I'm not really seeing the point compared to treating it as a COPY
option. I do not believe that anyone
Alvaro Herrera [EMAIL PROTECTED] writes:
- it is an option to COPY and CREATE TABLE AS, not GUC, not ALTER TABLE
AFAICS it could just happen automatically for CREATE TABLE AS; there's
no need for an option there, any more than there is for CREATE INDEX.
The only reason it needs to be an
I have been working on improving the COPY command performance and as a
result also came up with other thoughts that may possibly be better off
implemented in a new command (i.e LOAD DATA) rather than adding them to the
existing COPY.
The improvements I made were in the COPY parsing logic -
On Wed, 2005-06-01 at 11:55 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
4. Optionally, we set a flag on the table showing the whole table is
frozen. Anybody writing to this table subsequently will spoil this flag.
If the flag is set, all forms of VACUUM will return success
We have a whole TODO list of potential items for people to work on, and we
have several member of this list that work for universities in some capacity,
so istm we ought to give it a shot. I would think this is something that the
foundation would be good to be involved in as well, as it would
I think we definitely should submit PostgreSQL to Google.
Oleg
On Wed, 1 Jun 2005, Jonah H. Harris wrote:
Marc,
If you wanted to submit PostgreSQL to Google for this, I'd be willing to work
with any potentials. Should someone choose to work on PostgreSQL projects,
the money can go
On Wed, Jun 01, 2005 at 06:55:46PM +0100, Simon Riggs wrote:
On Wed, 2005-06-01 at 11:55 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
4. Optionally, we set a flag on the table showing the whole table is
frozen. Anybody writing to this table subsequently will spoil this
Simon Riggs [EMAIL PROTECTED] writes:
If the server crashes, we replay WAL. If we see a load start message, we
truncate the relation and note that a load has started. If there is WAL
data for the tuples, we replay it. If WAL replay ends without the load
transaction having successfully
My participation would be limited to the actual number of newcomers. I
feel comfortable helping 2 or 3 people; any more than that would impact
my clients and consulting time. Although, it would never hurt to have
additional mentors :).
Robert Treat wrote:
We have a whole TODO list of
Alvaro Herrera [EMAIL PROTECTED] writes:
On Wed, Jun 01, 2005 at 06:55:46PM +0100, Simon Riggs wrote:
We're holding the table lock and will continue to do so until end of
transaction. No transaction with an earlier id will ever see the data we
load because of the lock.
Suppose you load half
Are there any restrictions on 'mentor groups'? For instance, could we
create a 'mentors' mailing list, closed subscriptions, that contained
those willing to actively mentor, so that those being mentor'd have
multiple ppl's knowledge's to feed upon?
On Wed, 1 Jun 2005, Jonah H. Harris
One concern that was raised off of this list was the steep learning curve
to start with, to get to the point of beign able to do anything ...
Do we have any 'students' that are already up to speed, enough so that
they'd be able to accomplish something significant over a 2-3 month
period?
It occurs to me that at least on some OSes the WAL logs are being synced with
O_SYNC or its ilk. In those cases the writes should be guaranteed to be
written out in the order postgres wrote them. So if the tail end of the WAL
entry is there (is there any sort of footer?) then the entire entry
Greg Stark [EMAIL PROTECTED] writes:
It occurs to me that at least on some OSes the WAL logs are being synced with
O_SYNC or its ilk. In those cases the writes should be guaranteed to be
written out in the order postgres wrote them. So if the tail end of the WAL
entry is there (is there any
Not sure about the current 'students'. I need to take a look and see
what kind of somewhat easy stuff is on the TODO (I haven't seen it in
awhile).
I like your suggestion for the mailing list.
Marc G. Fournier wrote:
One concern that was raised off of this list was the steep learning
Hannu,
RAID10
Throughput report Y-axis is type of test X-axis is number of processes
Record size = 8 Kbytes
Output is in ops/sec
Initial write 1352.90
Rewrite 413.31
RAID5
Throughput report Y-axis is type of test X-axis is number of processes
Record size = 8
On Wed, 2005-06-01 at 14:24 -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Wed, Jun 01, 2005 at 06:55:46PM +0100, Simon Riggs wrote:
We're holding the table lock and will continue to do so until end of
transaction. No transaction with an earlier id will ever see the data
On Wed, 1 Jun 2005, Marc G. Fournier wrote:
One concern that was raised off of this list was the steep learning curve to
start with, to get to the point of beign able to do anything ...
Do we have any 'students' that are already up to speed, enough so that they'd
be able to accomplish
On Wed, 2005-06-01 at 14:14 -0400, Tom Lane wrote:
So what I'm thinking is we need no special WAL entries for this. What
we need is just an operating mode of COPY in which it doesn't WAL-log
its inserts, but instead fsyncs before completion, much like index build
does. For safety it must do
Marc G. Fournier wrote:
Do we have any 'students' that are already up to speed, enough so that
they'd be able to accomplish something significant over a 2-3 month period?
Well, I suppose now might be a good time to de-lurk. Hi, my name's
Meredith, I'm a PhD student at the University of Iowa,
Funny how things come full circle... in previous threads someone mentioned a
few low hanging fruit items, we should start there, and maybe get one of the
more hard-core hackers to go through the TODO list and mark up some other
items.
My take on the mentor thing was that the students could
'k, since there appears to be interest, I've tried to read a bit more up
on it, specifically the FAQs ... seems simple enough, but someone else may
have found a link that I haven't ...
Basically, developer (ie. Ramy Hassan) would go to:
http://code.google.com/soc_application.html
Jochem van Dieten wrote:
On 6/1/05, Bruce Momjian wrote:
Jochem van Dieten wrote:
Why only on an empty table? What is the problem with bypassing WAL on
any table as long as all files of that table are fsync'ed before
commit?
Because adding rows to a table might modify existing
On Wed, 2005-06-01 at 15:50 -0500, Meredith L. Patterson wrote:
Marc G. Fournier wrote:
Do we have any 'students' that are already up to speed, enough so that
they'd be able to accomplish something significant over a 2-3 month period?
Well, I suppose now might be a good time to de-lurk.
On Wed, 1 Jun 2005, Robert Treat wrote:
Funny how things come full circle... in previous threads someone mentioned a
few low hanging fruit items, we should start there, and maybe get one of the
more hard-core hackers to go through the TODO list and mark up some other
items.
My take on the
Alon Goldshuv wrote:
9) allow for Simon's WAL bypass.
I have surely missed some problems that hide behind the idea, but these
points make me believe that LOAD DATA is a good idea.
The community is unlikely to add a new LOAD DATA command that does
_almost_ everything COPY does. We are much
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Not unless you are proposing to change COPY to acquire a lock strong
enough to lock out other writers to the table for the duration ...
Well, if the table is initally empty, what harm is there in locking the
Simon Riggs wrote:
Is it possible that you could put sufficient of the application into
PostgreSQL to genericise some features? Stonebraker's Third Wave was
*all* about putting data intensive operations closer to where the data
is stored/accessed.
And just like that, a lightbulb goes off in
Bruce,
The problem with a new command is that it becomes unclear when you
should use COPY and when LOAD DATA, and it confuses users, and has
maintenance overhead. If Bizgres wants a new command name, go for it,
but it is unlikely that the community release is going to go in that
direction,
Bruce Momjian pgman@candle.pha.pa.us writes:
One idea would be to look at the table file size first. If it has zero
blocks, lock the table and if it still has zero blocks, do the no-WAL
copy.
I think that's a bad idea. It would make the behavior unpredictable
--- sometimes a COPY will take
Luke Lonergan [EMAIL PROTECTED] writes:
One of the reasons to consider a LOAD DATA command is that we can isolate
the need for performance improvements and special syntax from the concerns
of preserving the legacy behavior of COPY for use as the primary mechanism
for DUMP and RESTORE.
... and
On Wed, 2005-06-01 at 10:35 -0700, Alon Goldshuv wrote:
I have been working on improving the COPY command performance
Around 40% for 15 column (mixed types) table.
Around 90% for 1 column table.
Thats very cool.
2) A modified command syntax for introducing a direct single row error
On Wed, 2005-06-01 at 18:32 -0400, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
One idea would be to look at the table file size first. If it has zero
blocks, lock the table and if it still has zero blocks, do the no-WAL
copy.
I think that's a bad idea. It would make
Luke Lonergan wrote:
Bruce,
The problem with a new command is that it becomes unclear when you
should use COPY and when LOAD DATA, and it confuses users, and has
maintenance overhead. If Bizgres wants a new command name, go for it,
but it is unlikely that the community release is going
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
One idea would be to look at the table file size first. If it has zero
blocks, lock the table and if it still has zero blocks, do the no-WAL
copy.
I think that's a bad idea. It would make the behavior unpredictable
---
Simon Riggs wrote:
I'm not clear from all of those options whether we still need a LOAD
command, based upon other issues/comments raised on this thread.
However, there are some other arguments for why it might be a good idea
to have a LOAD DATA command separate from COPY. Certainly long term
Simon Riggs wrote:
On Wed, 2005-06-01 at 10:35 -0700, Alon Goldshuv wrote:
2) A modified command syntax for introducing a direct single row error
handling. By direct I mean - a row that if rejected from within the COPY
5) allow an ERRORLIMIT to allow control of aborting a load after a
Bruce,
The patch is not there to show that something is broken is it there to
show how things could be done in another way, which may or may not be more
desireable.
COPY works as designed. The idea that some guy we have never heard of
is going to appear and rewrite COPY's processing and tell
Tom,
... and instead, define some new behavior that will soon be considered
broken legacy code itself?
I'll not argue further about whether to have a separate LOAD command.
That's not as important as fixing the performance issues in the data load
path in PostgreSQL to me.
However, I find it
Alon Goldshuv wrote:
Bruce,
The patch is not there to show that something is broken is it there to
show how things could be done in another way, which may or may not be more
desireable.
Sure, we are always looking for ways to improve things.
COPY works as designed. The idea that some
1 - 100 of 118 matches
Mail list logo
