Re: Some memory allocations in gin fastupdate code are a bit brain dead

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Some memory allocations in gin fastupdate code are a bit brain dead
Дата
Msg-id 10273.1545146685@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Some memory allocations in gin fastupdate code are a bit brain dead  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: Some memory allocations in gin fastupdate code are a bit brain dead  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes:
> I recently stumbled upon the following code in ginfast.c:
> while (collector->ntuples + nentries > collector->lentuples)
> {
>     collector->lentuples *= 2;
>     collector->tuples = (IndexTuple *) repalloc(collector->tuples,
>       sizeof(IndexTuple) * collector->lentuples);
> }

I agree that's pretty stupid, but I wonder whether we should also try
harder in the initial-allocation path.  Right now, if the initial
pass through this code sees say 3 tuples to insert, it will then work
with 3 * 2^n entries in subsequent enlargements, which is likely to
be pretty inefficient.  Should we try to force the initial allocation
to be a power of 2?

Also, do we need to worry about integer overflow?

            regards, tom lane


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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: dropdb --force
Следующее
От: John Naylor
Дата:
Сообщение: Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)