On Fri, Apr 5, 2013 at 11:40 AM, Merlin Moncure wrote:
>
> On Fri, Apr 5, 2013 at 11:54 AM, Dave Johansen wrote:
> > On Sat, Feb 26, 2011 at 2:38 PM, Dave Johansen
> > wrote:
> >>
> >> Unfortunately, I'm running 8.3.3 and to my knowledge the windowing stuff
> >> wasn't added til 8.4.
> >> Dave
>
Hi Jeff,
I'ved tried this test using the -S flag './pgbench -c 4 -j 2 -T 600 -S
pgbench'
Desktop gives me
./pgbench -c 4 -j 2 -T 600 -S pgbench
starting vacuum...end.
transaction type: SELECT only
scaling factor: 1
query mode: simple
number of clients: 4
number of threads: 2
duration: 600 s
numb
Sorry Vasillis I missed you asking that I just did './pgbench -i pgbench'
didn't specific set any values. I can try some specific ones if you can
suggest any.
On 8 April 2013 21:28, Vasilis Ventirozos wrote:
>
>
>
> On Mon, Apr 8, 2013 at 11:18 PM, Mark Davidson wrote:
>
>> Wow my results are
On Mon, Apr 8, 2013 at 12:31 PM, Mark Davidson wrote:
> Thanks for your response Vasillis. I've run pgbench on both machines
> `./pgbench -c 10 -t 1 pgbench` getting 99.800650 tps on my local
> machine and 23.825332 tps on the server so quite a significant difference.
>
These results are alm
On Mon, Apr 8, 2013 at 11:18 PM, Mark Davidson wrote:
> Wow my results are absolutely appalling compared to both of those which is
> really interesting. Are you running postgres 9.2.4 on both instances? Any
> specific configuration changes?
> Thinking there must be something up with my setup to b
Wow my results are absolutely appalling compared to both of those which is
really interesting. Are you running postgres 9.2.4 on both instances? Any
specific configuration changes?
Thinking there must be something up with my setup to be getting such a low
tps compared with you.
On 8 April 2013 21:
-c 10 means 10 clients so that should take advantage of all your cores (see
bellow)
%Cpu0 : 39.3 us, 21.1 sy, 0.0 ni, 38.7 id, 0.9 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 38.0 us, 25.0 sy, 0.0 ni, 26.0 id, 4.2 wa, 0.0 hi, 6.8 si, 0.0 st
%Cpu2 : 39.3 us, 20.4 sy, 0.0 ni, 39.0 id, 1.3 wa, 0.0 hi, 0.0 si,
Thanks for your response Vasillis. I've run pgbench on both machines
`./pgbench -c 10 -t 1 pgbench` getting 99.800650 tps on my local
machine and 23.825332 tps on the server so quite a significant difference.
Could this purely be down to the CPU clock speed or is it likely something
else causin
Hello Mark,
PostgreSQL currently doesn't support parallel query so a faster cpu even if
it has less cores would be faster for a single query, about benchmarking
you can try pgbench that you will find in the contrib,
the execution plan may be different because of different statistics, have
you analy
Been trying to progress with this today. Decided to setup the database on
my local machine to try a few things and I'm getting much more sensible
results and a totally different query plan
http://explain.depesz.com/s/KGdin this case the query took about a
minute but does sometimes take around
80 se
Jeff Janes writes:
> On Sat, Apr 6, 2013 at 9:27 AM, Tom Lane wrote:
>> Yeah, eqjoinsel() is O(N^2) in the lengths of the MCV lists, in the
>> worst case where there's little overlap in the list memberships.
> I guess this pre-emptively answers a question I was intending to ask on
> performance:
On Sat, Apr 6, 2013 at 9:27 AM, Tom Lane wrote:
> Franck Routier writes:
> > Le 05/04/2013 16:17, Tom Lane a écrit :
> >> What have you got the statistics targets set to in this database?
>
> > Ok, the problem definitely comes from the default_statistics_target
> > which is obviously too high on
On Sun, Apr 07, 2013 at 09:27:42PM -0700, Nik Tek wrote:
> Thank you Depesz!
> But I have a naive question, why isn't a straight forword approach for
> postgres, unlike Oracle or MSSQL?
No idea. And how do you get memory usage in Oracle or MSSQL?
Best regards,
depesz
--
Sent via pgsql-perfor
13 matches
Mail list logo
