MBOX-Line: From arnt at gulbrandsen.priv.no  Tue Jun 15 00:38:58 2010
To: imap-protocol@u.washington.edu
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <201006150033.17670.witold.krecicki@firma.o2.pl>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
	<201006142330.15547.witold.krecicki@firma.o2.pl>
	<alpine.OSX.2.00.1006141445490.662@hsinghsing.panda.com>
	<201006150033.17670.witold.krecicki@firma.o2.pl>
Message-ID: <4C172E12.40600@gulbrandsen.priv.no>

On 06/15/2010 12:33 AM, Witold Kr?cicki wrote:
> On Tuesday 15 of June 2010 00:28:30 Mark Crispin wrote:
>> The correct design of a database is that COPY is fast and MOVE is nearly
>> as fast or even equal.
> So you state that (in a database language) INSERT ... SELECT should be faster
> than UPDATE? Do you know ANY database that works that way?

Actually, INSERT...SELECT can be faster than UPDATE, depending on the 
database design (such as if the db has point-in-time recovery without 
infringing an Oracle patent). However, MOVE should still be faster in 
total, since it needs fewer locks (two with table-level locking, vs. 
four for COPY/STORE/EXPUNGE, more in both cases with row-level locking) 
and there's only one commit phase instead of three.

Not that it matters ? a transactional database with point in time 
recovery is a robust, fine datastore, but "speed" is not a reason to 
pick that kind of datastore.

Arnt

