Re: snprintf.c hammering memset()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Mateusz Guzik <mjguzik(at)gmail(dot)com>
Subject: Re: snprintf.c hammering memset()
Date: 2018-10-01 23:52:40
Message-ID: 4353.1538437960@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> Mateusz Guzik was benchmarking PostgreSQL on FreeBSD investigating the
> kqueue thread and complained off-list about a lot of calls to memset()
> of size 256KB from dopr() in our snprintf.c code.

> Yeah, that says:
> PrintfArgType argtypes[NL_ARGMAX + 2];
> ...
> MemSet(argtypes, 0, sizeof(argtypes));

> PrintfArgType is an enum, and we define NL_ARGMAX as 16 if the OS
> didn't already define it. On FreeBSD 11, NL_ARGMAX was defined as 99
> in <limits.h>. On FreeBSD 12, it is defined as 65536... ouch. On a
> Debian box I see it is 4096.

> Is there any reason to use the OS definition here?

Ouch indeed. Quite aside from cycles wasted, that's way more stack than
we want this to consume. I'm good with forcing this to 16 or so ...
any objections?

(For reference, POSIX doesn't require NL_ARGMAX to be more than 9.)

(I wonder if this has anything to do with Andres' performance gripes.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-10-01 23:59:43 Re: snprintf.c hammering memset()
Previous Message Tom Lane 2018-10-01 23:31:31 Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)