Andrew Sullivan a écrit :
On Sun, Feb 29, 2004 at 10:43:34AM -0500, Tom Lane wrote:
general I think our VACUUM-based approach is superior to the
Oracle-style UNDO approach, because it pushes the maintenance overhead
out of foreground transaction processing and into a schedulable
background
On Sun, Feb 29, 2004 at 10:43:34AM -0500, Tom Lane wrote:
general I think our VACUUM-based approach is superior to the
Oracle-style UNDO approach, because it pushes the maintenance overhead
out of foreground transaction processing and into a schedulable
background process. Certainly any
Shridhar Daithankar
Recently, I ran a huge update on an Integer column affecting 100
million
rows in my database. What happened was my disk space increased in
size
and
my IO load was very high. It appears that MVCC wants to rewrite each
row
(each row was about 5kB due to a bytea column).
I use this type of approach when mirroring data from a foxpro database
(yuck) to a read-only postgres database. It is quicker and cleaner than
deleting all of the rows and inserting them again (TRUNCATE is not
transaction safe, which I need).
However, for this to be useful, your table must
Paul Tillotson [EMAIL PROTECTED] writes:
I use this type of approach when mirroring data from a foxpro database
(yuck) to a read-only postgres database. It is quicker and cleaner than
deleting all of the rows and inserting them again (TRUNCATE is not
transaction safe, which I need).
Just
On Tuesday 02 March 2004 06:29, Paul Tillotson wrote:
However, for this to be useful, your table must not have any indexes,
views, foreign keys, sequences, triggers, etc., or else you must be
prepared to re-create all of them using application level code.
Which isn't a big deal is it? You can
Jon Jensen wrote:
How would you do a rollback if an error occurred mid-query? How would you
keep your table from being a big pile of junk if a power failure happened
during the query?
As most non-MVCC database do: by writing WAL records.
In theory, it seems to me that we could implement an
Neil Conway [EMAIL PROTECTED] writes:
Jon Jensen wrote:
How would you do a rollback if an error occurred mid-query? How would you
keep your table from being a big pile of junk if a power failure happened
during the query?
As most non-MVCC database do: by writing WAL records.
In theory, it
On Tuesday 24 February 2004 22:13, Stephen wrote:
Hi,
Recently, I ran a huge update on an Integer column affecting 100 million
rows in my database. What happened was my disk space increased in size and
my IO load was very high. It appears that MVCC wants to rewrite each row
(each row was
Hi,
Recently, I ran a huge update on an Integer column affecting 100 million
rows in my database. What happened was my disk space increased in size and
my IO load was very high. It appears that MVCC wants to rewrite each row
(each row was about 5kB due to a bytea column). In addition, VACUUM
On Tue, 24 Feb 2004, Stephen wrote:
It came to my mind that what if there could be a mechanism in place to allow
overwriting portions of the same row *whenever possible* instead of creating
a new row as MVCC would require.
How would you do a rollback if an error occurred mid-query? How would
11 matches
Mail list logo
