Re: FUNC_MAX_ARGS benchmarks

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Thomas Lockhart <lockhart(at)fourpalms(dot)org>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FUNC_MAX_ARGS benchmarks
Date: 2002-08-10 23:21:17
Message-ID: 200208102321.g7ANLHs11473@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


OK, seems we have not come to a decision yet on this.

Do we have agreement to increate FUNC_MAX_ARGS to 32?

NAMEDATALEN will be 64 or 128 in 7.3. At this point, we better decide
which one we prefer.

The conservative approach would be to go for 64 and perhaps increase it
again in 7.4 after we get feedback and real-world usage. If we go to
128, we will have trouble decreasing it if there are performance
problems.

---------------------------------------------------------------------------

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
> >> I'm not sure about the trend of increasing standard deviation --- that
> >> may reflect more disk I/O being done, and perhaps more checkpoints
> >> occurring during the test. But in any case it's clear that there's a
> >> nontrivial runtime cost here. Does a 10% slowdown bother you?
>
> > Hmmm -- didn't Neil do some kind of test that had different results,
> > i.e. not much performance difference?
>
> Well, one person had reported a 10% slowdown in pgbench, but Neil saw
> a 10% speedup. Given the well-known difficulty of getting any
> reproducible numbers out of pgbench, I don't trust either number very
> far; but unless some other folk are willing to repeat the experiment
> I think we can only conclude that pgbench isn't affected much by
> NAMEDATALEN.
>
> > I wonder if the large number of
> > DDL commands in installcheck doesn't skew the results against longer
> > NAMEDATALEN compared to other benchmarks?
>
> Depends on what you consider skewed, I suppose. pgbench touches only a
> very small number of relations, and starts no new backends over the
> length of its run, thus everything gets cached and stays cached. At
> best I'd consider it an existence proof that some applications won't be
> hurt.
>
> Do you have another application you'd consider a more representative
> benchmark?
>
> regards, tom lane
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-08-11 00:22:38 Re: FUNC_MAX_ARGS benchmarks
Previous Message Rod Taylor 2002-08-10 22:33:42 Re: AnonCVS woes