On Thu, 7 May 2009, Tom Lane wrote:
The tables will be created and used in schema 'a', and the effective
search path depth will be the same.
The case to be concerned about here is where the search_path changes
between initialization and the pgbench run, which certainly isn't
impossible.
Greg Smith gsm...@gregsmith.com writes:
On Thu, 7 May 2009, Tom Lane wrote:
The tables will be created and used in schema 'a', and the effective
search path depth will be the same.
The case to be concerned about here is where the search_path changes
between initialization and the pgbench
On Wed, 2009-05-06 at 15:18 -0400, Tom Lane wrote:
Dickson S. Guedes lis...@guedesoft.net writes:
Em Qua, 2009-05-06 s 09:37 -0400, Tom Lane escreveu:
Seems like the right policy for that is run pgbench in its own
database.
A text warning about this could be shown at start of pgbench
On Thu, May 7, 2009 at 10:12 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2009-05-06 at 15:18 -0400, Tom Lane wrote:
Dickson S. Guedes lis...@guedesoft.net writes:
Em Qua, 2009-05-06 s 09:37 -0400, Tom Lane escreveu:
Seems like the right policy for that is run pgbench in its own
On Thu, 2009-05-07 at 11:14 -0400, Robert Haas wrote:
We should check they are the correct tables before we just drop them.
Perhaps check for the comment Tables for pgbench application. Not
production data on the tables, which would be nice to add anyway.
I bet it would be just as good
* Robert Haas robertmh...@gmail.com [090507 11:15]:
I bet it would be just as good and a lot simpler to do what someone
suggested upthread, namely s/^/pgbench_/
That has the legacy compatibility problem...
But seeing as legacy has a:
SET search_path TO public;
And uses plain table
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2009-05-07 at 11:14 -0400, Robert Haas wrote:
We should check they are the correct tables before we just drop them.
Perhaps check for the comment Tables for pgbench application. Not
production data on the tables, which would be nice to add
Aidan Van Dyk ai...@highrise.ca writes:
... couldn't we just
make new pgbench refer to tables as schema.table where schema is
public?
I'd prefer not to do that because it changes the amount of parsing work
demanded by the benchmark. Maybe not by enough to matter ... or maybe
it does.
On Thu, 2009-05-07 at 12:47 -0400, Tom Lane wrote:
Well, pgbench has been coded this way since forever and we've only seen
this one report of trouble. Still, I can't object very hard to renaming
the tables to pgbench_accounts etc --- it's a trivial change and the
only thing it could break is
* Tom Lane t...@sss.pgh.pa.us [090507 12:53]:
Aidan Van Dyk ai...@highrise.ca writes:
... couldn't we just
make new pgbench refer to tables as schema.table where schema is
public?
I'd prefer not to do that because it changes the amount of parsing work
demanded by the benchmark. Maybe
On Thu, 2009-05-07 at 12:58 -0400, Aidan Van Dyk wrote:
True enough... What about making the prefix be configurable, so by
default, it could be pgbench_, it could be set to (to force it to
use old pgbench names) or set to something. to get it to use a
different schema (noting that the
* Joshua D. Drake j...@commandprompt.com [090507 13:02]:
On Thu, 2009-05-07 at 12:58 -0400, Aidan Van Dyk wrote:
True enough... What about making the prefix be configurable, so by
default, it could be pgbench_, it could be set to (to force it to
use old pgbench names) or set to
On Thu, 2009-05-07 at 09:53 -0700, Joshua D. Drake wrote:
On Thu, 2009-05-07 at 12:47 -0400, Tom Lane wrote:
Well, pgbench has been coded this way since forever and we've only seen
this one report of trouble. Still, I can't object very hard to renaming
the tables to pgbench_accounts etc
Joshua D. Drake j...@commandprompt.com writes:
On Thu, 2009-05-07 at 12:58 -0400, Aidan Van Dyk wrote:
True enough... What about making the prefix be configurable, so by
default, it could be pgbench_, it could be set to (to force it to
use old pgbench names) or set to something. to get it to
Joshua D. Drake j...@commandprompt.com writes:
--- a/contrib/pgbench/pgbench.c
+++ b/contrib/pgbench/pgbench.c
@@ -357,8 +357,6 @@ doConnect(void)
return NULL;
}
- executeStatement(conn, SET search_path = public);
-
return conn;
}
Applied along
On Thu, 7 May 2009, Aidan Van Dyk wrote:
But by dropping the search_path, you're necessarily changing the catalog
comparisons and lookups anyways, because your now taking a random
search path to follow (which could have multiple entries in it) instead
of one guaranteed to be a single, useable
Greg Smith gsm...@gregsmith.com writes:
On Thu, 7 May 2009, Aidan Van Dyk wrote:
You are correct here. Right now, pgbench is guaranteed to be running
against a search_path with only one entry in it. If someone runs the new
version against a configuration with something like:
On Tue, 5 May 2009, Tom Lane wrote:
I agree that it probably wasn't considered carefully whether pg_bench
should do that; but does anyone see a reason not to change it?
I thought of one pretty weak use-case for not making this change, but
would wager the additional flexibility here is far
Greg Smith gsm...@gregsmith.com writes:
I once did some pgbench testing on a system that included a real
accounts table in a named schema. pgbench -i will execute drop table
if exists accounts. It had already accidentally wiped out the copy of
the accounts table on the system during an
Em Qua, 2009-05-06 às 09:37 -0400, Tom Lane escreveu:
Greg Smith gsm...@gregsmith.com writes:
I once did some pgbench testing on a system that included a real
accounts table in a named schema. pgbench -i will execute drop table
if exists accounts. It had already accidentally wiped out
Dickson S. Guedes wrote:
Em Qua, 2009-05-06 às 09:37 -0400, Tom Lane escreveu:
Seems like the right policy for that is run pgbench in its own
database.
A text warning about this could be shown at start of pgbench if the
target database isn't named pgbench, for examplo, or just some text
Dickson S. Guedes lis...@guedesoft.net writes:
Em Qua, 2009-05-06 às 09:37 -0400, Tom Lane escreveu:
Seems like the right policy for that is run pgbench in its own
database.
A text warning about this could be shown at start of pgbench if the
target database isn't named pgbench, for examplo,
On Wed, 2009-05-06 at 15:13 -0400, Alvaro Herrera wrote:
Dickson S. Guedes wrote:
Em Qua, 2009-05-06 às 09:37 -0400, Tom Lane escreveu:
Seems like the right policy for that is run pgbench in its own
database.
A text warning about this could be shown at start of pgbench if the
Alvaro Herrera alvhe...@commandprompt.com writes:
I think it would be better that the schema is specified on the command
line.
Surely that's more work than the issue is worth. It's also inconvenient
to use, because you'd have to remember to give the switch both for the
-i run and the normal
On Wed, 2009-05-06 at 17:42 -0300, Dickson S. Guedes wrote:
Em Qua, 2009-05-06 às 16:27 -0400, Tom Lane escreveu:
Alvaro Herrera alvhe...@commandprompt.com writes:
I think it would be better that the schema is specified on the command
line.
Surely that's more work than the issue is
Em Qua, 2009-05-06 às 16:27 -0400, Tom Lane escreveu:
Alvaro Herrera alvhe...@commandprompt.com writes:
I think it would be better that the schema is specified on the command
line.
Surely that's more work than the issue is worth. It's also inconvenient
to use, because you'd have to
Em Qua, 2009-05-06 às 13:49 -0700, Joshua D. Drake escreveu:
On Wed, 2009-05-06 at 17:42 -0300, Dickson S. Guedes wrote:
Em Qua, 2009-05-06 às 16:27 -0400, Tom Lane escreveu:
Alvaro Herrera alvhe...@commandprompt.com writes:
I think it would be better that the schema is specified on the
Joshua D. Drake j...@commandprompt.com writes:
On Wed, 2009-05-06 at 17:42 -0300, Dickson S. Guedes wrote:
But, there is the possibility that someone are using an automated script
that could be broken by this change?
Only if the role pgbench is using as an explicit search_path set.
Even
Dickson S. Guedes lis...@guedesoft.net writes:
So, in a way to avoid the scenario where a ROLE has an explicit
search_path set to schemes that already have tables named same as the
pgbench's tables, doesn't makes sense also create a pgbench_ suffix
for them?
Hm, just rename the standard
Hello,
I have been doing some testing with pgbench and I realized that it
forces the use of public as its search_path. This is bad if:
* You want to run multiple pgbench instances within the same database
* You don't want to use public (for whatever reason)
This patch removes that ability and
Joshua D. Drake j...@commandprompt.com writes:
I have been doing some testing with pgbench and I realized that it
forces the use of public as its search_path. This is bad if:
* You want to run multiple pgbench instances within the same database
* You don't want to use public (for whatever
31 matches
Mail list logo
