Re: why do hash index builds use smgrextend() for new splitpoint pages

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: why do hash index builds use smgrextend() for new splitpoint pages
Дата
Msg-id CAA4eK1Lp1Zvt+L3hjqeUS4se259Fse32w=SRxzHH=ExwVB7ErA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: why do hash index builds use smgrextend() for new splitpoint pages  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Fri, Feb 25, 2022 at 8:54 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Feb 25, 2022 at 4:41 AM Melanie Plageman
> <melanieplageman@gmail.com> wrote:
> >
> > I'm trying to understand why hash indexes are built primarily in shared
> > buffers except when allocating a new splitpoint's worth of bucket pages
> > -- which is done with smgrextend() directly in _hash_alloc_buckets().
> >
> > Is this just so that the value returned by smgrnblocks() includes the
> > new splitpoint's worth of bucket pages?
> >
> > All writes of tuple data to pages in this new splitpoint will go
> > through shared buffers (via hash_getnewbuf()).
> >
> > I asked this and got some thoughts from Robert in [1], but I still don't
> > really get it.
> >
> > When a new page is needed during the hash index build, why can't
> > _hash_expandtable() just call ReadBufferExtended() with P_NEW instead of
> > _hash_getnewbuf()? Does it have to do with the BUCKET_TO_BLKNO mapping?
> >
>
> We allocate the chunk of pages (power-of-2 groups) at the time of
> split which allows them to appear consecutively in an index.
>

I think allocating chunks of pages via "ReadBufferExtended() with
P_NEW" will be time-consuming as compared to what we do now.

-- 
With Regards,
Amit Kapila.



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

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Buffer Manager and Contention
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Buffer Manager and Contention