2010/4/7 Greg Smith g...@2ndquadrant.com:
Merlin Moncure wrote:
On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg has the right idea: show debug_assertions.
why not the entire set of configure options?
Given that the standard way to find those is pg_config,
Josh Berkus j...@agliodbs.com wrote:
SELECT 'DBD::Pg ping test';
In our test, which does 5801 of these pings during the test, they take
an average of 15x longer to execute on 9.0 as 8.4 ( 0.77ms vs. 0.05ms ).
Any clue why this would be?
Did you use the same configure options between
On Tue, Apr 6, 2010 at 1:47 AM, Josh Berkus j...@agliodbs.com wrote:
Hackers,
Continuing the performance test:
DBD, like a number of monitoring systems, does pings on the database
which look like this:
SELECT 'DBD::Pg ping test';
In our test, which does 5801 of these pings during the
Josh Berkus j...@agliodbs.com writes:
Continuing the performance test:
DBD, like a number of monitoring systems, does pings on the database
which look like this:
SELECT 'DBD::Pg ping test';
In our test, which does 5801 of these pings during the test, they take
an average of 15x longer to
On Apr 6, 2010, at 2:32 AM, Takahiro Itagaki wrote:
In our test, which does 5801 of these pings during the test, they take
an average of 15x longer to execute on 9.0 as 8.4 ( 0.77ms vs. 0.05ms ).
Any clue why this would be?
Did you use the same configure options between them?
Yes.
For
On Apr 6, 2010, at 6:07 AM, Merlin Moncure wrote:
In our test, which does 5801 of these pings during the test, they take
an average of 15x longer to execute on 9.0 as 8.4 ( 0.77ms vs. 0.05ms ).
did your pings change?
No.
David
--
Sent via pgsql-hackers mailing list
On Apr 6, 2010, at 7:28 AM, Tom Lane wrote:
There's something wrong with your test setup. Or, if you'd like me to
think that there isn't, provide a self-contained test case. I ran a
small program that does
for (i = 0; i 1; i++)
{
res = PQexec(conn, SELECT
Tom Lane t...@sss.pgh.pa.us writes:
Josh Berkus j...@agliodbs.com writes:
Continuing the performance test:
DBD, like a number of monitoring systems, does pings on the database
which look like this:
SELECT 'DBD::Pg ping test';
In our test, which does 5801 of these pings during the test,
On Tue, Apr 6, 2010 at 12:08 PM, David E. Wheeler da...@kineticode.com wrote:
On Apr 6, 2010, at 2:32 AM, Takahiro Itagaki wrote:
In our test, which does 5801 of these pings during the test, they take
an average of 15x longer to execute on 9.0 as 8.4 ( 0.77ms vs. 0.05ms ).
Any clue why this
On Apr 6, 2010, at 9:08 AM, David E. Wheeler wrote:
For example, --enable-debug or --enable-cassert.
No.
Oh FFS! I was looking at the wrong build script. It was indeed built with
--enable-cassert --enable-debug. Grrr.
Well, that's likely the culprit right there. I'm rebuilding without
On Apr 6, 2010, at 10:17 AM, Tom Lane wrote:
So I'm not sure where your 15x is coming from, but I don't see it.
By stupidly having configured with --enable-cassert --enable-debug without
realizing it. I've just rebuilt without them and run the tests again using the
default postgresql.conf and
On Apr 6, 2010, at 10:52 AM, David E. Wheeler wrote:
Oh FFS! I was looking at the wrong build script. It was indeed built with
--enable-cassert --enable-debug. Grrr.
Well, that's likely the culprit right there. I'm rebuilding without those now
and hopefully my tests will be back down to
David E. Wheeler da...@kineticode.com writes:
On Apr 6, 2010, at 10:17 AM, Tom Lane wrote:
So I'm not sure where your 15x is coming from, but I don't see it.
By stupidly having configured with --enable-cassert --enable-debug without
realizing it. I've just rebuilt without them and run the
David E. Wheeler wrote:
By stupidly having configured with --enable-cassert --enable-debug without
realizing it. I've just rebuilt without them and run the tests again using the
default postgresql.conf and I'm back down to 57s and 46s over two runs.
Every performance test I run,
On Apr 6, 2010, at 11:15 AM, Tom Lane wrote:
By stupidly having configured with --enable-cassert --enable-debug without
realizing it. I've just rebuilt without them and run the tests again using
the default postgresql.conf and I'm back down to 57s and 46s over two runs.
Huh. I'm still
David E. Wheeler da...@kineticode.com writes:
On Apr 6, 2010, at 11:15 AM, Tom Lane wrote:
Huh. I'm still curious, because in my test the overhead of those
options seemed to be about 3x. So there's still something considerably
different between what you did and what I did.
Are you doing
On Apr 6, 2010, at 12:50 PM, Tom Lane wrote:
I hadn't, but since you mention it: 10 iterations take about 7.5sec
with non-assert CVS HEAD and 15sec with asserts, on a 2008 Macbook Pro.
Color me still confused.
Well it's not just pings that the bricolage tests were running, of course.
2010/4/6 Tom Lane t...@sss.pgh.pa.us:
David E. Wheeler da...@kineticode.com writes:
On Apr 6, 2010, at 11:15 AM, Tom Lane wrote:
Huh. I'm still curious, because in my test the overhead of those
options seemed to be about 3x. So there's still something considerably
different between what you
Pavel Stehule pavel.steh...@gmail.com writes:
it is little bit offtopic. Can we add info about assertation to
version() output?
Greg has the right idea: show debug_assertions.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Josh, might you have got the numbers wrong when trying to match up query
runtimes to their queries in the CSVLOG output? That might explain it. Most
of the queries were BINDs.
I swept up some DEALLOCATEs by acccident, but those don't appreciably
affect the final numbers.
--
On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
it is little bit offtopic. Can we add info about assertation to
version() output?
Greg has the right idea: show debug_assertions.
why not the entire set of configure options?
Merlin Moncure mmonc...@gmail.com writes:
On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg has the right idea: show debug_assertions.
why not the entire set of configure options?
We've discussed that before. pg_config already provides that info,
and there was some
Merlin Moncure wrote:
On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg has the right idea: show debug_assertions.
why not the entire set of configure options?
Given that the standard way to find those is pg_config, there's a couple
of reasons why not to
Hackers,
Continuing the performance test:
DBD, like a number of monitoring systems, does pings on the database
which look like this:
SELECT 'DBD::Pg ping test';
In our test, which does 5801 of these pings during the test, they take
an average of 15x longer to execute on 9.0 as 8.4 ( 0.77ms vs.
24 matches
Mail list logo
