Changes to stringinfo.c

Поиск
Список
Период
Сортировка
От David Rowley
Тема Changes to stringinfo.c
Дата
Msg-id CAApHDvpK5ROBNOZFtOQE4ChfE7=-VgDwKP8J3UD4i=Nf13g5OQ@mail.gmail.com
обсуждение исходный текст
Ответы Re: Changes to stringinfo.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
<div dir="ltr">Hi,<br /><br />I'm just looking at the changed code in commit 3147acd63e0135aff9a6c4b01d861251925d97d9
andI'm wondering if we should perhaps test the performance of this before assuming too much that it is an improvement.
I'ma bit concerned that now if there is not enough space in the buffer that we only now allocate what is needed,
whereasbefore we would double the buffer's size. I guess this will save memory in many cases, but I'm a bit worried
thatwe'll see quite a big drop in performance when we next try to append to the string and have to reallocate space
again.<br/><br />In my patch I ended up only using the value from appendStringInfoVA as a guide, where I still doubled
thebuffer if "needed" was less than the current buffer size, but if it was larger I kept doubling the buffer size until
itwas bigger than "needed".<br /><br />I don't yet have any examples of work loads where I suspect this will slow down,
butI guess any strings that are built using appendStringInfo that go over 1024 bytes could see a bit of a slow down
sinceit will have to allocate space for each append after the 1024 byte mark.<br /><br />Any thoughts on this?<br /><br
/>Regards<br/><br />David<br /></div> 

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: dsm use of uint64
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Pattern matching operators a index