On 17/12/2010, at 9:20 PM, Pierre C wrote:
>
>> fc=# explain analyse select collection, period, tariff, sum(bytesSent),
>> sum(bytesReceived), sum(packets), max(sample), (starttime / 3600) * 3600 as
>> startchunk from sample_20101001 where starttime between 1287493200 and
>> 1290171599 and
On 17/12/2010, at 8:27 PM, Filip Rembiałkowski wrote:
>
> 2010/12/17 Royce Ausburn
> Hi all,
>
> I have a table that in the typical case holds two minute sample data for a
> few thousand sources. Often we need to report on these data for a particular
> source over a particular time period a
On 12/18/10 20:42, tuanhoanganh wrote:
Here is my result without -C
pgbench -h 127.0.0.1 -p -U postgres -c 100 -t 10 -s 10 pgbench
You really should replace "-t 10" with something like "-T 60" or more.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make
On Sat, Dec 18, 2010 at 11:13 AM, tuanhoanganh wrote:
> My app has ~ 20 exe file, each of exe create new connect to postgesql
But how often do they do that? Does each exe make a new connection,
do one transaction, and then exit? Or does each exe make one
connection, do one transaction, then clo
Here is my result without -C
pgbench -h 127.0.0.1 -p -U postgres -c 100 -t 10 -s 10 pgbench
Scale option ignored, using pgbench_branches table count = 10
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 10
query mode: simple
number of clients: 100
number of threads: 1
My app has ~ 20 exe file, each of exe create new connect to postgesql and
there are 10-30 user use my application so I need -C to check PostgreSQL
performance.
I will test without -C option. But is there any way to decrease connect time
when there are 200 process, each of process will create new c
No, I don't use SSL. Here is my pg_hba.conf
# IPv4 local connections:
hostall all 0.0.0.0/0trust
# IPv6 local connections:
hostall all ::1/128 trust
On Sun, Dec 19, 2010 at 1:35 AM, Kevin Grittner wrote:
> > tuan
On Sat, Dec 18, 2010 at 10:15 AM, tuanhoanganh wrote:
> I have server computer install Windows 2008R2, PostgreSQL 9.0.1 64 bit, 8G
...
> pgbench -h 127.0.0.1 -p 5433 -U postgres -c 100 -t 10 -C -s 10 pgbench
Why the -C option? You are essentially benchmarking how fast you can
make new connecti
> tuanhoanganh wrote:
> tps = 20.143494 (including connections establishing)
> tps = 256.630260 (excluding connections establishing)
>
> Why pgbench on my server is very low or is it common value with my
> server ?
Those numbers look pretty low to me. I would start with looking at
why it is
I have server computer install Windows 2008R2, PostgreSQL 9.0.1 64 bit, 8G
RAM, RAID 10 - 4 disks, dedicated server
Here is config of postgresql.conf after running pgtune
default_statistics_target = 100 # pgtune wizard 2010-12-15
maintenance_work_mem = 480MB # pgtune wizard 2010-12-15
constraint_e
Rauan Maemirov wrote:
> EXPLAIN SELECT [...]
Please show us the results of EXPLAIN ANALYZE SELECT ...
Also, please show us the table layout (including indexes), and
details about your hardware and PostgreSQL configuration. See this
page for details:
http://wiki.postgresql.org/wiki/SlowQue
Tom Polak wrote:
Hi neighbor! (We're just up I90/I39 a bit.)
> What kind of performance can I expect out of Postgres compare to
> MSSQL?
I can't speak directly to MS SQL Server 2000, but Sybase and ASE have
common roots; I think MS SQL Server 2000 is still using the engine
that they inherit
> The real performance problem with RAID 5 won't show up until a drive
> dies and it starts rebuilding
I don't agree with that. RAID5 is very slow for random writes, since
it needs to :
"The real problem" is when RAID5 loses a drive and goes from "acceptable"
kind of slow, to "someone'
2010/12/18 Gael Le Mignot :
> Hello Scott!
>
> Fri, 17 Dec 2010 19:06:15 -0700, you wrote:
>
> > On Fri, Dec 17, 2010 at 10:32 AM, Craig James
> > wrote:
> >> RAID5 is a Really Bad Idea for any database. It is S...L...O...W. It
> does
> >> NOT give better redundancy and security; RAID 10 wi
Hello Scott!
Fri, 17 Dec 2010 19:06:15 -0700, you wrote:
> On Fri, Dec 17, 2010 at 10:32 AM, Craig James
> wrote:
>> RAID5 is a Really Bad Idea for any database. It is S...L...O...W. It does
>> NOT give better redundancy and security; RAID 10 with a battery-backed RAID
>> controller card
15 matches
Mail list logo
