Re: _mdfd_getseg can be expensive

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: _mdfd_getseg can be expensive
Дата
Msg-id 20160831213720.4axsjt25xaco5d4m@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: _mdfd_getseg can be expensive  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: _mdfd_getseg can be expensive  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On 2016-08-31 14:09:47 -0700, Peter Geoghegan wrote:
> On Thu, Aug 18, 2016 at 5:26 PM, Andres Freund <andres@anarazel.de> wrote:
> > Rebased version attached. A review would be welcome. Plan to push this
> > forward otherwise in the not too far away future.
> 
> This looks good.

Thanks for looking!


> The only thing that stuck out to any degree is that we don't grow the
> "reln->md_seg_fds[forknum]" array within the new _fdvec_resize()
> function geometrically. In other words, we don't separately keep track
> of the array size and allocated size, and grow the allocated size
> using the doubling strategy that you see in many places.

I can't really see that being worth the code here. The cost of
open()/lseek()'ing etc. is going to dwarf the cost of this.


Regards,

Andres



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Replace use malloc() & friend by memory contexts for plperl and pltcl
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)