Re: Buglist

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Vivek Khera <khera(at)kcilink(dot)com>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: Buglist
Date: 2003-08-20 15:58:57
Message-ID: 20030820084933.Q7072-100000@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 20 Aug 2003, Vivek Khera wrote:

> >>>>> "BW" == Bruno Wolff, <Bruno> writes:
>
> >> to see it incremental. This would result in pretty much near zero
> >> internal fragmentation, I think.
>
> BW> Why do you care about about the details of the implementation (rather than
> BW> the performance)? If it were faster to do it that way, that's how it would
> BW> have been done in the first place. The cost of doing the above is almost
> BW> certainly going to be an overall performance loser.
>
> I care for the performance. And how are you so sure that it was
> faster the way it is now? Are you sure it was not done this way
> because of ease of implementation?
>
> Seriously, how much slower can it be if the backend were to do the
> checking for external references upon updating/deleting a row? The
> cost would be distributed across time as opposed to concentrated at
> once within a vacuum process. I am fairly certian it would reduce
> disk bandwidth requirements since at least one necessary page will
> already be in memory.

In general, excepting a case with only one session running, I would expect
there to exist one or more transactions that can see the old state of the
row.

I would think it'd be something like:

T1: begin;
T1: update foo set bar=cheese where id=3;
T2: begin;
T2: select * from foo;
-- this should see the old state of the row, so that update better
-- not have removed the old one.
T1: end;
-- at this point read committed transactions may see the new
-- state, unless it's currently running a query which is accessing
-- that table, and in practice it's probably more complicated than
-- that (since you might run functions tha access the table).
-- You'd presumably need to wait until say the end of that full
-- statement at the very least. And any serializable transactions
-- would probably mean you can't do it either.

Under some circumstances it might be better, yes. And there are ways to
do things that don't involve non-overwriting (like Oracle's system) but
they all have downsides. This might not be the best solution, but you're
going to have to put alot more work into showing that your solution is
better. ;)

Browse pgsql-general by date

  From Date Subject
Next Message expect 2003-08-20 16:01:24 Re: 7.4b1 vs 7.3.4 performance
Previous Message Josh Berkus 2003-08-20 15:39:28 Need concrete "Why Postgres not MySQL" bullet list