Re: No heap lookups on index

Поиск
Список
Период
Сортировка
От Jonah H. Harris
Тема Re: No heap lookups on index
Дата
Msg-id 36e682920601190626p28403587j5108757cfb1144cd@mail.gmail.com
обсуждение исходный текст
Ответ на Re: No heap lookups on index  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: No heap lookups on index  (Greg Stark <gsstark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Unique constraints for non-btree indexes
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: restrict column-level GRANTs to a single relation?