Re: pgbench MAX_ARGS

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgbench MAX_ARGS
Date: 2019-02-26 12:19:50
Message-ID: alpine.DEB.2.21.1902261102180.6915@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Simon,

> pgbench has a strange restriction to only allow 10 arguments, which is too
> low for some real world uses.
>
> Since MAX_ARGS is only used for an array of pointers and an array of
> integers increasing this should not be a problem, so increase value to 255.

Fine with me on principle.

Patch applies cleanly, compiles.

However, 3 TAP tests fails on the "too many argument" test case, what a
surprise:-)

Probably I would have chosen a smaller value, eg 32 or 64, but I have not
seen your use case.

> While there, correct an off by one error in the error message when you hit
> the limit. The highest argument id is MAX_ARGS - 1, but the max number of
> arguments is MAX_ARGS.

Argh! Indeed.

I notice that there is no documentation update, which just shows that
indeed there are no documentation about the number of arguments, maybe the
patch could add a sentence somewhere? There is no limit discussed in the
PREPARE documentation, I tested up to 20. I'd sugggest to add something at
the end of the paragraph about variable substitution in the "Custom
Script" section, eg "A maximum of XX variable references can appear within
an SQL command.".

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2019-02-26 12:25:34 Oddity with parallel safety test for scan/join target in grouping_planner
Previous Message Stephen Frost 2019-02-26 12:15:41 Re: Remove Deprecated Exclusive Backup Mode