From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Greg Stark <gsstark(at)mit(dot)edu>, Rod Taylor <pg(at)rbt(dot)ca>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and |
Date: | 2005-12-30 22:36:24 |
Message-ID: | 87mzii8b6f.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
As far as EXCLUSIVE or COPY LOCK goes, I think this would be useful
functionality but perhaps there doesn't have to be any proprietary user
interface to it at all. Why not just check if the conditions are already
present to allow the optimization and if so go ahead.
That is, if the current transaction already has an exclusive lock on the table
and there are no indexes (and PITR isn't active) then Postgres could go ahead
and use the same WAL skipping logic as the other operations that already so
so. This would work for inserts whether coming from COPY or plain SQL INSERTs.
The nice thing about this is that the user's SQL wouldn't need any proprietary
extensions at all. Just tell people to do
BEGIN;
LOCK TABLE foo;
COPY foo from ...
COMMIT;
There could be a COPY LOCK option to obtain a lock, but it would be purely for
user convenience so they don't have to bother with BEGIN and COMMIt.
The only downside is a check to see if an exclusive table lock is present on
every copy and insert. That might be significant but perhaps there are ways to
finess that. If not perhaps only doing it on COPY would be a good compromise.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-12-30 22:46:45 | Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and |
Previous Message | Martijn van Oosterhout | 2005-12-30 21:46:42 | Re: Removing SORTFUNC_LT/REVLT |