Re: No heap lookups on index

As an Oracle internals person myself, I don't see how making a comparison
between the specifics of Oracle's MVCC to PostgreSQL's MVCC is relevant to
this discussion.

As does *MOST* other commercial databases, Oracle's storage manager performs
an update-in-place whereas PostgreSQL's (for the most part) does not. There
are several ways to implement update-in-place, and Oracle has chosen their
own rollback segment methodology which has issues that without tuning, are
major hassles. I'm not saying that one is better than the other in ALL
cases, but I and many other Oracle consultants have tuned Oracle
installations to eliminate the headaches others in this list have
mentioned. Any knowledgable Oracle person evaluating PostgreSQL that may be
reading this list is just going to see it as a lot of anti-Oracle discussion
with no basis in fact.

Regardless, there is NO WAY to perform an apples-to-apples comparison
between the implementations, locking strategies, etc. as the MVCC
implementations and goals are completely different. In short, Oracle's
implementation is not perfect; neither is ours. Oracle's initial design (as
a commercial database) is much different than PostgreSQL's (as a research
database).

While I'm always game for looking at other implementations when designing
and discussing new features for PostgreSQL, let's focus on making PostgreSQL
better rather than spending time discussing unrealistic comparisons.

If we want to do a comparison on the how/why Oracle's index implementation
is faster in the context of this situation and how we could make
PostgreSQL's faster, let's stick to that.

On 1/19/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > I wonder if the bitmap can actually be one bit per page actually.
>
> Yeah, I think we'd agreed that per-page was the way to go. Per-tuple
> bitmaps are painful to manage because of the variable number of tuples
> per page. And really all you need to know is whether to read the page
> or not --- once you have, examining multiple tuples on it doesn't cost
> much.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>