From: | Rod Taylor <pg(at)rbt(dot)ca> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, David Scott <davids(at)apptechsys(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: No heap lookups on index |
Date: | 2006-01-19 02:02:28 |
Message-ID: | 1137636148.15377.292.camel@home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Thu, 2006-01-19 at 09:18 +0800, Christopher Kings-Lynne wrote:
> > Oracle does, but you pay in other ways. Instead of keeping dead tuples
> > in the main heap, they shuffle them off to an 'undo log'. This has some
> > downsides:
> >
> > Rollbacks take *forever*, though this usually isn't much of an issue
> > unless you need to abort a really big transaction.
>
> It's a good point though. Surely a database should be optimised for the
> most common operation
Yes.
> - commits, rather than rollbacks?
Commits are most common because most databases are optimized for them.
Lots of programs go through a ton pre-checking to avoid a rollback that
they don't need to do under PostgreSQL.
I've found that for small systems I tend to rely very heavily on
frequent vacuums and database level exceptions for virtually all data
checking. Rollbacks are nearly as common as commits in those
environments if not more-so.
--
From | Date | Subject | |
---|---|---|---|
Next Message | Redefined Horizons | 2006-01-19 02:59:58 | Data type that corresponds to bigserial... |
Previous Message | Michael Glaesemann | 2006-01-19 01:47:49 | Re: Surrogate keys (Was: enums) |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-01-19 03:03:33 | Re: pgxs/windows |
Previous Message | ITAGAKI Takahiro | 2006-01-19 02:00:00 | TODO-Item: B-tree fillfactor control |