Re: copy.c allocation constant
От
Bruce Momjian
Тема
Re: copy.c allocation constant
Дата
Msg-id
20180124031414.GD17109@momjian.us
Ответ на
copy.c allocation constant (Andrew Dunstan)
Список
Дерево обсуждения
copy.c allocation constant Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Re: copy.c allocation constant Bruce Momjian <bruce@momjian.us>
Re: copy.c allocation constant Tomas Vondra <tomas.vondra@2ndquadrant.com>
Re: copy.c allocation constant Bruce Momjian <bruce@momjian.us>
Re: copy.c allocation constant Robert Haas <robertmhaas@gmail.com>
Re: copy.c allocation constant Andres Freund <andres@anarazel.de>
Re: copy.c allocation constant Robert Haas <robertmhaas@gmail.com>
Re: copy.c allocation constant Andres Freund <andres@anarazel.de>
Re: copy.c allocation constant Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: copy.c allocation constant Andres Freund <andres@anarazel.de>
Re: copy.c allocation constant Thomas Munro <thomas.munro@enterprisedb.com>
Re: copy.c allocation constant Bruce Momjian <bruce@momjian.us>
Re: copy.c allocation constant Tom Lane <tgl@sss.pgh.pa.us>
Re: copy.c allocation constant Thomas Munro <thomas.munro@enterprisedb.com>
On Tue, Nov 28, 2017 at 11:51:28AM -0500, Andrew Dunstan wrote: > > > While reading copy.c I noticed this line: > > > #define RAW_BUF_SIZE 65536 /* we palloc RAW_BUF_SIZE+1 bytes */ > > > Doesn't that seem rather odd? If we're adding 1 wouldn't it be better as > 65535 so we palloc a power of 2? > > > I have no idea if this affects performance, but it did strike me as strange. Coming in late here, but it does seem very odd. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-hackers по дате отправления
