On Wed, 2005-11-30 at 02:10 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
[...context omitted...]
We would need to flush all the blocks in the table out of cache at
commit time, for that table only.
This seems striking close to the Old Concept of temp tables, which
we got
Simon Riggs wrote:
On Tue, 2005-11-29 at 18:51 -0500, Bruce Momjian wrote:
Please let me back up and ask a more simplistic question. I understand
the idea of allowing COPY to insert rows with less locking, but I am
wondering about the NOLOGGING idea. On commit, we must guarantee that
On Tue, Nov 29, 2005 at 01:35:09PM +0100, Harald Fuchs wrote:
In article [EMAIL PROTECTED],
Jim C. Nasby [EMAIL PROTECTED] writes:
On Sun, Nov 27, 2005 at 07:44:55PM +, Simon Riggs wrote:
not have any unique indexes or row triggers. It should be possible to
take advantage of this
In article [EMAIL PROTECTED],
Jim C. Nasby [EMAIL PROTECTED] writes:
On Sun, Nov 27, 2005 at 07:44:55PM +, Simon Riggs wrote:
not have any unique indexes or row triggers. It should be possible to
take advantage of this automatically when those requirements are met,
without any new
Harald Fuchs [EMAIL PROTECTED] writes:
In article [EMAIL PROTECTED],
Jim C. Nasby [EMAIL PROTECTED] writes:
Does that mean that this fast copy would end up not re-using space on
pages that have space available? ISTM that's something users would want
to be able to over-ride. In fact, it seems
Simon Riggs wrote:
As a further enhancement, I would also return to the NOLOGGING option
for COPY. Previously we had said that COPY LOCK was the way to go -
taking a full table lock to prevent concurrent inserts to a block from a
COPY that didn't write WAL and another backend which wanted to
Bruce Momjian pgman@candle.pha.pa.us writes:
One idea for default behavior would be to use EXCLUSIVE when the table
is zero size. I think that would do pg_dump and most of the user cases,
and of course users could override the default by using a keyword. We
could emit a NOTICE if an an
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
One idea for default behavior would be to use EXCLUSIVE when the table
is zero size. I think that would do pg_dump and most of the user cases,
and of course users could override the default by using a keyword. We
could emit a
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Something that would probably be reasonable, and require *no* weird new
syntax, is to shortcut in a COPY into a table created in the current
transaction. I believe we still keep a flag in the relcache indicating
whether that's the
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Something that would probably be reasonable, and require *no* weird new
syntax, is to shortcut in a COPY into a table created in the current
transaction. I believe we still keep a flag in the relcache indicating
On Tue, 2005-11-29 at 14:17 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
As a further enhancement, I would also return to the NOLOGGING option
for COPY. Previously we had said that COPY LOCK was the way to go -
taking a full table lock to prevent concurrent inserts to a block from a
On Tue, 2005-11-29 at 15:15 -0500, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Something that would probably be reasonable, and require *no* weird new
syntax, is to shortcut in a COPY into a table created in the current
On Tue, 2005-11-29 at 14:56 -0500, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Something that would probably be reasonable, and require *no* weird new
syntax, is to shortcut in a COPY into a table created in the current
transaction. I believe we still
Simon Riggs [EMAIL PROTECTED] writes:
Tom Lane wrote:
Log, yes, unless it's a temp table. The point is we could avoid taking
buffer content locks. Come to think of it, we could implement that
trivially in the heapam.c routines; it would then apply to any table
update whether generated by
On Mon, 2005-11-28 at 09:26 -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't see why couldn't have an additional index access method entry
point to insert multiple rows on one call.
I think Simon was mainly on about the idea of inserting multiple *heap*
entries with
On Tue, 2005-11-29 at 15:58 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Tom Lane wrote:
Log, yes, unless it's a temp table. The point is we could avoid taking
buffer content locks. Come to think of it, we could implement that
trivially in the heapam.c routines; it would
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2005-11-29 at 15:58 -0500, Tom Lane wrote:
anyway, I had second thoughts about this while
eating lunch. A buffer for a new table can reasonably be assumed not to
be accessed by any other backend, but we can *not* make that assumption
for the
Please let me back up and ask a more simplistic question. I understand
the idea of allowing COPY to insert rows with less locking, but I am
wondering about the NOLOGGING idea. On commit, we must guarantee that
all the rows are in the table, so what advantage is there to a NOLOGGING
option?
On Tue, 2005-11-29 at 18:51 -0500, Bruce Momjian wrote:
Please let me back up and ask a more simplistic question. I understand
the idea of allowing COPY to insert rows with less locking, but I am
wondering about the NOLOGGING idea. On commit, we must guarantee that
all the rows are in the
Simon Riggs [EMAIL PROTECTED] writes:
[...context omitted...]
We would need to flush all the blocks in the table out of cache at
commit time, for that table only.
This seems striking close to the Old Concept of temp tables, which
we got rid of for good-and-sufficient reasons. You might want
On Sun, Nov 27, 2005 at 05:45:31PM -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
COPY FROM can read in sufficient rows until it has a whole block worth
of data, then get a new block and write it all with one pair of
BufferLock calls.
Comments?
I don't see any way to do
On Mon, 2005-11-28 at 09:40 +0100, Martijn van Oosterhout wrote:
On Sun, Nov 27, 2005 at 05:45:31PM -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
COPY FROM can read in sufficient rows until it has a whole block worth
of data, then get a new block and write it all with one
On Sun, 2005-11-27 at 17:45 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
COPY FROM can read in sufficient rows until it has a whole block worth
of data, then get a new block and write it all with one pair of
BufferLock calls.
Comments?
I don't see any way to do this
Simon Riggs wrote:
On Sun, 2005-11-27 at 17:45 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
COPY FROM can read in sufficient rows until it has a whole block worth
of data, then get a new block and write it all with one pair of
BufferLock calls.
Comments?
I
On Mon, 2005-11-28 at 00:56 +, Simon Riggs wrote:
On Sun, 2005-11-27 at 17:45 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
COPY FROM can read in sufficient rows until it has a whole block worth
of data, then get a new block and write it all with one pair of
On Mon, Nov 28, 2005 at 09:39:36AM +, Simon Riggs wrote:
On Mon, 2005-11-28 at 09:40 +0100, Martijn van Oosterhout wrote:
Whatever happened to that idea to build as entire datafile with COPY or
some external tool and simply copy it into place and update the
catalog?
What's wrong with
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't see why couldn't have an additional index access method entry
point to insert multiple rows on one call.
I think Simon was mainly on about the idea of inserting multiple *heap*
entries with one call, ie, only one cycle of locking a heap buffer.
On Sun, Nov 27, 2005 at 07:44:55PM +, Simon Riggs wrote:
not have any unique indexes or row triggers. It should be possible to
take advantage of this automatically when those requirements are met,
without any new options. Just as it was with Seq Scans, this is worth
about 10% reduction in
Since we just discussed using a multi-row per buffer lock technique with
Seq Scans, it seems appropriate to discuss a similar technique with COPY
FROM that I had been mulling over.
COPY FROM can read in sufficient rows until it has a whole block worth
of data, then get a new block and write it
Simon Riggs [EMAIL PROTECTED] writes:
COPY FROM can read in sufficient rows until it has a whole block worth
of data, then get a new block and write it all with one pair of
BufferLock calls.
Comments?
I don't see any way to do this without horrible modularity violations.
The COPY code has no
30 matches
Mail list logo
