Re: Bugs/slowness inserting and indexing cubes

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: Bugs/slowness inserting and indexing cubes
Дата
Msg-id CAPpHfdvVC961FoBMA1SU7NBbQ5GtLwCt9jfzPffnFA8ZExcLHg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Bugs/slowness inserting and indexing cubes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Bugs/slowness inserting and indexing cubes  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
On Wed, Feb 15, 2012 at 2:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alexander Korotkov <aekorotkov@gmail.com> writes:
> ITSM, I found the problem. This piece of code is triggering an error. It
> assumes each page of corresponding to have initialized buffer. That should
> be true because we're inserting index tuples from up to down while
> splits propagate from down to up.
> But this assumptions becomes false we turn buffer off in the root page. So,
> root page can produce pages without initialized buffers when splits.

Hmm ... can we tighten the error check rather than just remove it?  It
feels less than safe to assume that a hash-entry-not-found condition
*must* reflect a corner-case situation like that.  At the very least
I'd like to see it verify that we'd turned off buffering before deciding
this is OK.  Better, would it be practical to make dummy entries in the
hash table even after turning buffers off, so that the logic here
becomes

       if (!found) error;
       else if (entry is dummy) return without doing anything;
       else proceed;

                       regards, tom lane

Ok, there is another patch fixes this problem. Instead of error triggering remove it adds empty buffers on root page split if needed.

------
With best regards,
Alexander Korotkov.
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zhou Han
Дата:
Сообщение: Re: client performance v.s. server statistics
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: pg_test_fsync performance