Re: No heap lookups on index - Mailing list pgsql-hackers

From Jonah H. Harris
Subject Re: No heap lookups on index
Date
Msg-id 36e682920601190626p28403587j5108757cfb1144cd@mail.gmail.com
Whole thread Raw
In response to Re: No heap lookups on index  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: No heap lookups on index  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
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@sss.pgh.pa.us> wrote:
Greg Stark <gsstark@mit.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

pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Unique constraints for non-btree indexes
Next
From: Peter Eisentraut
Date:
Subject: Re: restrict column-level GRANTs to a single relation?