On Wed, Jun 20, 2012 at 8:43 AM, Andy Colson wrote:
>> this is an obligation from the past:
>> http://archives.postgresql.org/pgsql-performance/2012-05/msg00017.php
>>
>> the same test, that did ~230 results, is now doing ~700 results. that
>> is, BTW even better than mssql.
>>
>> the ultimate sol
On 6/20/2012 1:01 AM, Eyal Wilde wrote:
Hi, all.
this is an obligation from the past:
http://archives.postgresql.org/pgsql-performance/2012-05/msg00017.php
the same test, that did ~230 results, is now doing ~700 results. that
is, BTW even better than mssql.
the ultimate solution for that probl
Hi, all.
this is an obligation from the past:
http://archives.postgresql.org/pgsql-performance/2012-05/msg00017.php
the same test, that did ~230 results, is now doing ~700 results. that is,
BTW even better than mssql.
the ultimate solution for that problem was to NOT to do "ON COMMIT DELETE
ROWS
On Wed, May 9, 2012 at 2:11 AM, Robert Klemme
wrote:
> On Fri, May 4, 2012 at 3:04 PM, Merlin Moncure wrote:
>
>> let's see the query plan...when you turned it off, did it go faster?
>> put your suspicious plans here: http://explain.depesz.com/
>
> I suggest to post three plans:
>
> 1. insert int
On Fri, May 4, 2012 at 3:04 PM, Merlin Moncure wrote:
> let's see the query plan...when you turned it off, did it go faster?
> put your suspicious plans here: http://explain.depesz.com/
I suggest to post three plans:
1. insert into temp table
2. access to temp table before analyze
3. access to
On Thu, May 3, 2012 at 12:07 PM, Eyal Wilde wrote:
> guess what:
>
> after reducing bo (blocks out) to ~10% by using a ramdisk (improving overall
> performance by ~15-20%), i now managed to reduced it to ~3% by removing
> the "analyze temp-table" statements.
> it also :
> reduced b (Process w
guess what:
after reducing bo (blocks out) to ~10% by using a ramdisk (improving
overall performance by ~15-20%), i now managed to reduced it to ~3% by
removing the "analyze temp-table" statements.
it also :
reduced b (Process which are waiting for I/O) to zero
reduced wa (percentage of time
On Sun, Apr 29, 2012 at 8:21 AM, Eyal Wilde wrote:
> hi, all.
>
> well, i wondered why there is high rate of bo (blocks out). the procedure is
> practically read-only during the whole test. although it's not strictly
> read-only, because in a certain condition, there might be writing to a
> certai
hi, all.
well, i wondered why there is high rate of bo (blocks out). the procedure
is practically read-only during the whole test. although it's not strictly
read-only, because in a certain condition, there might be writing to a
certain table. but that condition can not be met during this test.
s
On Wed, Apr 18, 2012 at 2:32 AM, Eyal Wilde wrote:
> hi all,
>
> i ran vmstat during the test :
>
> [yb@centos08 ~]$ vmstat 1 15
> procs ---memory-- ---swap-- -io --system--
> -cpu-
> r b swpd free buff cache si so bi bo in cs us sy id
> wa st
On 4/18/2012 2:32 AM, Eyal Wilde wrote:
hi all,
i ran vmstat during the test :
[yb@centos08 ~]$ vmstat 1 15
procs ---memory-- ---swap-- -io --system-- -cpu-
r b swpd free buff cache si sobibo in cs us sy id wa st
2 0 0 6118620 1605
hi all,
i ran vmstat during the test :
[yb@centos08 ~]$ vmstat 1 15
procs ---memory-- ---swap-- -io --system--
-cpu-
r b swpd free buff cache si sobibo in cs us sy id
wa st
0 0 0 6131400 160556 111579200 112 22 17
On 15/04/12 13:43, Eyal Wilde wrote:
"version";"PostgreSQL 9.1.2 on x86_64-unknown-linux-gnu, compiled by gcc
(GCC) 4.1.2 20080704 (Red Hat 4.1.2-46), 64-bit"
You've probably checked this, but if not it's worth making sure your
disk I/O is roughly equivalent for the two operating-systems. It
On 4/15/2012 7:43 AM, Eyal Wilde wrote:
hi,
thanks a lot to all of you for your help.
(i'm sorry i did not know how to reply to a certain message)
i found that the best number of active connections is indeed 8-10. with
8-10 active connections postgresql did ~170 "account-id"s. this is still
on
hi,
thanks a lot to all of you for your help.
(i'm sorry i did not know how to reply to a certain message)
i found that the best number of active connections is indeed 8-10. with
8-10 active connections postgresql did ~170 "account-id"s. this is still
only half of what mssql did, but it now make
On Wed, Apr 11, 2012 at 5:11 PM, Eyal Wilde wrote:
> hi,
>
> i had a stored procedure in ms-sql server. this stored procedure gets a
> parameter (account-id), dose about 20 queries, fills some temporary tables,
> and finally, returns a few result-sets. this stored procedure converted to
> stored f
On Fri, Apr 13, 2012 at 2:49 PM, Steve Crawford
wrote:
> Well, the fact that temporary and unlogged cannot be simultaneously
> specified *is* documented:
>
> CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT
> EXISTS ] table_name
>
> But it would probably be worth adding
On 04/13/2012 09:43 AM, Claudio Freire wrote:
On Fri, Apr 13, 2012 at 1:36 PM, Steve Crawford
wrote:
If they are permanent tables used for temporary storage then making them
unlogged may be beneficial. But actual temporary tables *are* unlogged and
attempting to create an unlogged temporary ta
On Fri, Apr 13, 2012 at 1:36 PM, Steve Crawford
wrote:
>>
> If they are permanent tables used for temporary storage then making them
> unlogged may be beneficial. But actual temporary tables *are* unlogged and
> attempting to create an unlogged temporary table will raise an error.
Interesting, ye
On 04/13/2012 08:04 AM, Claudio Freire wrote:
...You might want to try unlogged temp tables, which more
closely resemble mssql temp tables.
If they are permanent tables used for temporary storage then making them
unlogged may be beneficial. But actual temporary tables *are* unlogged
and attemp
On Wed, Apr 11, 2012 at 7:11 PM, Eyal Wilde wrote:
> in a single execution postgresql may be less the twice slower than ms-sql,
> but in 20 simultaneous clients, it's about 6 times worse. why is that?
>
> the hardware is one 4-core xeon. 8GB of ram. the database size is just a few
> GB's. centos-6
Eyal Wilde wrote:
> now, i run a test that simulates 20 simultaneous clients, asking
> for "account-id" randomly. once a client get a result, it
> immediately asks for another one. the test last 5 seconds. i use
> a connection pool (with Tomcat web-server). the pool is
> automatically increased
On 04/11/2012 06:11 PM, Eyal Wilde wrote:
hi,
i had a stored procedure in ms-sql server. this stored procedure gets
a parameter (account-id), dose about 20 queries, fills some temporary
tables, and finally, returns a few result-sets. this stored procedure
converted to stored function in pos
hi,
i had a stored procedure in ms-sql server. this stored procedure gets a
parameter (account-id), dose about 20 queries, fills some temporary tables,
and finally, returns a few result-sets. this stored procedure converted to
stored function in postgresql (9.1). the result-sets are being returned
24 matches
Mail list logo
