pgbench / compatibility with old(er) releases
Hi,
I'm running some tests comparing benchmarks on a range of versions,
going back to 8.0 (mostly because of curiosity, but actually for
practical reasons too).
I've decided to use the pgbench from 9.3, mostly to make the results
more comparable and because of features not available in older releases
(aggregation of transaction log, number of threads, ...), but this
causes issues on old releases because of features not available in the
really old releases - I've found these, so far:
(a) specifying fillfactor in CREATE TABLE
(b) DROP TABLE IF EXISTS
(c) application_name used for the connection
I do understand the versions up to 8.3 are unsupported (or soon will
be), but I think it's handy to be able to run current pgbench on those
versions. So I propose to:
(a) add --no-fillfactor that actually disables adding it to the
CREATE TABLE (now it adds default 100)
(b) add --no-appname that disables adding it to the connection (BTW
why not to allow custom appname? I'm thinking about multiple
pgbench instances running at the same time, or so, but on second
thought I've never done that.)
(c) do not use "IF EXISTS" but do that the old way (check if the
table exists in a separate command)
Opinions? Objections?
regards
Tomas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tomas Vondra <tv@fuzzy.cz> writes:
I do understand the versions up to 8.3 are unsupported (or soon will
be), but I think it's handy to be able to run current pgbench on those
versions. So I propose to:
(a) add --no-fillfactor that actually disables adding it to the
CREATE TABLE (now it adds default 100)
(b) add --no-appname that disables adding it to the connection (BTW
why not to allow custom appname? I'm thinking about multiple
pgbench instances running at the same time, or so, but on second
thought I've never done that.)
(c) do not use "IF EXISTS" but do that the old way (check if the
table exists in a separate command)
Opinions? Objections?
TBH this seems like way too much cruft to be added in support of
what are after all *unsupported* releases. And how far back do
we stop, anyway?
I'd suggest you test all the branches with the newest pgbench version
that happens to work with the oldest branch you care about.
Having said that, it seems like (a) could be fixed with about a one-line
change, if we simply made it not add the "with (fillfactor=%d)" clause
when fillfactor was at 100. And I'm not clear why (b) is a problem;
libpq already takes care of suppressing application_name when connecting
to old servers.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 18.8.2013 17:54, Tom Lane wrote:
TBH this seems like way too much cruft to be added in support of what
are after all *unsupported* releases. And how far back do we stop,
anyway?I'd suggest you test all the branches with the newest pgbench
version that happens to work with the oldest branch you care about.
That won't give me the 9.3-only features (that I really want/need).
Having said that, it seems like (a) could be fixed with about a
one-line change, if we simply made it not add the "with
(fillfactor=%d)" clause when fillfactor was at 100. And I'm not
Yeah, that seems line a nice solution - no additional option.
Another solution is to use custom scripts, and only use pgbench to
execute them. That'd solve the IF EXISTS problem too.
clear why (b) is a problem; libpq already takes care of suppressing
application_name when connecting to old servers.
Hmmm, I'm getting this in the log (when connection to 8.0.0):
FATAL: unrecognized configuration parameter "application_name"
but it seems to be working. I'm wondering if FATAL is appropriate here.
Tomas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers