On Sat, 2008-05-03 at 09:11 -0700, Christophe wrote:
I will have a log table which, once a day or so, is copied to a file
(for movement to a data warehouse), and the log table emptied.
...
Is there a better way to handle this kind of thing that I'm
missing?
Anyone care to comment
In article [EMAIL PROTECTED], Tom Lane [EMAIL PROTECTED] wrote:
% If you can't tolerate locking out writers for that long, you won't
% be able to use TRUNCATE. The operation I think you were imagining is
%
% BEGIN;
% SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
% COPY log TO 'filename-path';
%
Patrick TJ McPhee wrote:
How about something along the lines of
BEGIN;
ALTER TABLE log RENAME to log_old;
CREATE TABLE log(...);
COMMIT;
BEGIN;
LOCK table log_old;
COPY log_old TO 'filename-path';
DROP TABLE log_old;
COMMIT;
I believe this will keep the writers writing while keeping the
On May 3, 2008, at 9:29 PM, Patrick TJ McPhee wrote:
How about something along the lines of
BEGIN;
ALTER TABLE log RENAME to log_old;
CREATE TABLE log(...);
COMMIT;
BEGIN;
LOCK table log_old;
COPY log_old TO 'filename-path';
DROP TABLE log_old;
COMMIT;
I believe this will keep the writers
Hi,
I will have a log table which, once a day or so, is copied to a file
(for movement to a data warehouse), and the log table emptied. For
performance, the log table on the production system has no indexes,
and is write-only. (The unload process is the only reader.)
To unload it, I
Christophe [EMAIL PROTECTED] writes:
I will have a log table which, once a day or so, is copied to a file
(for movement to a data warehouse), and the log table emptied. For
performance, the log table on the production system has no indexes,
and is write-only. (The unload process is the
On May 3, 2008, at 9:56 AM, Tom Lane wrote:
This is
a great deal less efficient than TRUNCATE, but it's secure for
concurrent insertions, which TRUNCATE is definitely not.
Exactly my question; thank you!
-- Xof
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
