"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Bruce Momjian said:
> > DROP would drop the table on a restart
> > after a non-clean shutdown. It would do _no_ logging on the table and
> > allow concurrent access, plus index access. DELETE is the same as
> > DROP, but it just truncates the table (perhaps TRUNCATE is a better
> > word).
> >
> > EXCLUSIVE would allow only a single session to modify the table, and
> > would do all changes by appending to the table, similar to COPY LOCK.
> > EXCLUSIVE would also not allow indexes because those can not be
> > isolated like appending to the heap. EXCLUSIVE would write all dirty
> > shared buffers for the table and fsync them before committing. SHARE
> > is the functionality we have now, with full logging.
>
> I an horribly scared that this will be used as a "performance boost" for
> normal use. I would at least like to see some restrictions that make it
> harder to mis-use. Perhaps restrict to superuser?
Well that's its whole purpose. At least you can hardly argue that you didn't
realize the consequences of "DELETE ROWS ON RECOVERY"... :)
Some thoughts:
a) I'm not sure I understand the purpose of EXCLUSIVE. When would I ever want to
use it instead of DELETE ROWS?
b) It seems like the other feature people were talking about of not logging
for a table created within the same transaction should be handled by
having this flag implicitly set for any such newly created table.
Ie, the test for whether to log would look like:
if (!table->logged && table->xid != myxid) ...
c) Every option in ALTER TABLE should be in CREATE TABLE as well.
d) Yes as someone else mentioned, this should only be allowable on a table
with no foreign keys referencing it.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
