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 proc
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 ca
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).
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 not
>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
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 Or
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 wa
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 t
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 overwri
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 woul
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 needs
11 matches
Mail list logo
