Bruce Momjian writes:
> 1) Run this script and record the time reported:
> ftp://candle.pha.pa.us/pub/postgresql/mypatches/stat.script
One thing you neglected to specify is that the test must be done on a
NON ASSERT CHECKING build of CVS HEAD (or recent head, at least).
On these trivial "S
Bruce Momjian wrote:
> Stefan Kaltenbrunner wrote:
>> Bruce Momjian wrote:
>>> OK, based on reports I have seen, generally stats_query_string adds 50%
>>> to the total runtime of a "SELECT 1" query, and the patch reduces the
>>> overhead to 25%.
>> that is actually not true for both of the platform
Stefan Kaltenbrunner wrote:
> Bruce Momjian wrote:
> > OK, based on reports I have seen, generally stats_query_string adds 50%
> > to the total runtime of a "SELECT 1" query, and the patch reduces the
> > overhead to 25%.
>
> that is actually not true for both of the platforms(a slow OpenBSD
> 3.9
Bruce Momjian wrote:
> OK, based on reports I have seen, generally stats_query_string adds 50%
> to the total runtime of a "SELECT 1" query, and the patch reduces the
> overhead to 25%.
that is actually not true for both of the platforms(a slow OpenBSD
3.9/x86 and a very fast Linux/x86_64) I teste
OK, based on reports I have seen, generally stats_query_string adds 50%
to the total runtime of a "SELECT 1" query, and the patch reduces the
overhead to 25%.
However, that 25% is still much too large. Consider that "SELECT 1" has
to travel from psql to the server, go through the
parser/optimize
"Bruce Momjian" wrote
>
> Any idea why there is such a variance in the result? The second run
> looks quite slow.
>
No luck so far. It is quite repeatble in my machine -- runing times which
show a long execution time: 2, 11, 14, 21 ... But when I do strace, the
weiredness disappered totally. H
Qingqing Zhou wrote:
>
> "Bruce Momjian" wrote
> >
> > > -- After patch --
> > >
> > > real0m1.275s
> > > user0m0.097s
> > > sys 0m0.160s
> > >
> > > real0m4.063s
> > > user0m0.663s
> > > sys 0m0.377s
> > >
> > > real0m1.259s
> > > user0m0.073s
> > > sys 0m0.16
"Bruce Momjian" wrote
>
> > -- After patch --
> >
> > real0m1.275s
> > user0m0.097s
> > sys 0m0.160s
> >
> > real0m4.063s
> > user0m0.663s
> > sys 0m0.377s
> >
> > real0m1.259s
> > user0m0.073s
> > sys 0m0.160s
>
> I assume the above is just running the same te
Qingqing Zhou wrote:
>
> "Tom Lane" <[EMAIL PROTECTED]> wrote
> >
> > Hm? I don't see any improvement there:
> >
>
> I was referening this sentence, though I am not sure why that's the
> expectation:
> >
> > "Bruce Momjian" wrote
> > If the patch worked, the first and third times will be simila
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> wrote
>> Hm? I don't see any improvement there:
> I was referening this sentence, though I am not sure why that's the
> expectation:
>> "Bruce Momjian" wrote
>> If the patch worked, the first and third times will be sim
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> Hm? I don't see any improvement there:
>
I was referening this sentence, though I am not sure why that's the
expectation:
>
> "Bruce Momjian" wrote
> If the patch worked, the first and third times will be similar, and
> the second time will be high.
>
-
Josh Berkus wrote:
> Bruce,
>
> > The report is incomplete. I need three outputs:
> >
> > stats off
> > stats on
> > stats on, patched
> >
> > He only reported two sets of results.
>
> You need stats off, patched too.
No need --- stats off, patched too, should be the same as stats o
Josh Berkus writes:
> You need stats off, patched too.
Shouldn't really be necessary, as the code being patched won't be
executed if stats aren't being collected...
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'k
Bruce,
> The report is incomplete. I need three outputs:
>
> stats off
> stats on
> stats on, patched
>
> He only reported two sets of results.
You need stats off, patched too.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast
Bruce Momjian wrote:
> Would some people please run the attached test procedure and report back
> the results? I basically need to know the patch is an improvement on
> more platforms than just my own. Thanks
Debian Sarge/AMD64 Kernel 2.6.16.16 (all tests done multiple times with
variation of l
Bruce Momjian wrote:
> Would some people please run the attached test procedure and report back
> the results? I basically need to know the patch is an improvement on
> more platforms than just my own. Thanks
OpenBSD 3.9-current/x86:
without stats:
0m6.79s real 0m1.56s user 0m1.12s
Tom Lane wrote:
> "Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> > Obviously it matches your expectation.
>
> Hm? I don't see any improvement there:
>
> > --Before patch --
> > real0m1.149s
> > real0m1.121s
> > real0m1.128s
>
> > -- After patch --
> > real0m1.275s
> > real0m4
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> Obviously it matches your expectation.
Hm? I don't see any improvement there:
> --Before patch --
> real0m1.149s
> real0m1.121s
> real0m1.128s
> -- After patch --
> real0m1.275s
> real0m4.063s
> real0m1.259s
Bruce Momjian wrote:
> Would some people please run the attached test procedure and report
> back the results? I basically need to know the patch is an
> improvement on more platforms than just my own. Thanks
>
>
---
>
[s
"Bruce Momjian" wrote
>
> Would some people please run the attached test procedure and report back
> the results? I basically need to know the patch is an improvement on
> more platforms than just my own. Thanks
>
Obviously it matches your expectation.
uname: Linux amd64 2.6.9-5.13smp #1 SMP
20 matches
Mail list logo
