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, whi
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 advan
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 tha
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 wa
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
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?
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
>> fo
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 routi
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*
> ent
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 gener
On Tue, 2005-11-29 at 14:56 -0500, Tom Lane wrote:
> Bruce Momjian 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
On Tue, 2005-11-29 at 15:15 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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.
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
Tom Lane wrote:
> Bruce Momjian 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
> >> wheth
Bruce Momjian 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 case ...
> So
Tom Lane wrote:
> Bruce Momjian 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 a
Bruce Momjian 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 exclusive lock is used w
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 t
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
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
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
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 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 wr
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
>
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.
> >
> > > C
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
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
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
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 h
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 all
30 matches
Mail list logo
