Thanks Igor.
I am going to test with pgbouncer. Will let you know.
Thanks,
Anne
-Original Message-
From: Igor Neyman [mailto:iney...@perceptron.com]
Sent: Monday, May 06, 2013 7:04 PM
To: Anne Rosset; k...@rice.edu
Cc: pgsql-performance@postgresql.org
Subject: RE: [PERFORM
ser1439'::text))
Total runtime: 2666.011 ms
effective_cache_size| 512MB
Thanks,
Anne
-Original Message-
From: Igor Neyman [mailto:iney...@perceptron.com]
Sent: Monday, May 06, 2013 10:13 AM
To: Anne Rosset; k...@rice.edu
Cc: pgsql-performance@postgresql.org
Subject: RE:
Sent: Monday, May 06, 2013 10:12 AM
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Deterioration in performance when query executed in
multi threads
Anne Rosset, 06.05.2013 19:00:
> Postgres version: 9.0.13
>
>> Work_mem is set to 64MB
>> Shared_buffer to 240MB
no we haven't switched or tested yet with pgbouncer. We would like to do
a bit more analysis before trying this.
Thanks for your help,
Anne
-Original Message-
From: Igor Neyman [mailto:iney...@perceptron.com]
Sent: Monday, May 06, 2013 7:06 AM
To: Anne Rosset; k...@rice.edu
Cc:
Hi all,
We are running a stress test that executes one select query with multiple
threads.
The query executes very fast (10ms). It returns 100 rows. I see deterioration
in the performance when we have multiple threads executing the query. With 100
threads, the query takes between 3s and 8s.
I
bPlan 1
-> Index Scan using mntr_subscr_user on mntr_subscription
(cost=0.00..8.47 rows=1 width=9) (actual time=1.170..1.
170 rows=0 loops=177)
Index Cond: ((($0)::text = (object_key)::text) AND ((user_id)::text
= 'user1439'::text))
Total runtime: 1793.203 ms
(42 rows)
Work
: Wednesday, May 01, 2013 9:27 AM
To: Anne Rosset
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Deterioration in performance when query executed in
multi threads
On Wed, May 01, 2013 at 04:07:55PM +, Anne Rosset wrote:
> Hi Ken,
> Thanks for your answer. My test is actually runnin
...@rice.edu]
Sent: Wednesday, May 01, 2013 7:13 AM
To: Anne Rosset
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Deterioration in performance when query executed in
multi threads
On Wed, May 01, 2013 at 02:05:06PM +, Anne Rosset wrote:
> Hi all,
> We are running a stress tes
Hi all,
We are running a stress test that executes one select query with multiple
threads.
The query executes very fast (10ms). It returns 100 rows. I see deterioration
in the performance when we have multiple threads executing the query. With 100
threads, the query takes between 3s and 8s.
I
Hi,
We are seeing some overall performance degradation in our application since we
installed the security release. Other commits were also done at the same time
in the application so we don't know yet if the degradation has any relationship
with the security release.
While we are digging into th
Hi all,
I have this simple query that has performance issue. I am assuming there is
something wrong in our configuration. Can someone point me to the right
direction? (our work_mem is set to 64MB)
srdb=> explain analyze 013-04-15 16:51:20,223 INFO
[com.vasoftware.sf.server.common.querygenera
Hi,
I have read a lot of different information about the benefits of using
numerical primary key vs alphanumerical primary key(small size). And what I am
gathering is that for performance there is no more great advantage.
It seems like now RDBMS in general, postgres in particular handles pretty w
7)
Index Cond: ((sfuser.id)::text = (role_user.user_id)::text)
Total runtime: 4657.488 ms
(16 rows)
Is there anything that can be done. For instance for the 1s in the index scan
on sfuser?
Thanks,
Anne
-Original Message-
From: t...@fuzzy.cz [mailto:t...@fuzzy.cz]
Sent: Satu
Hi,
I am trying to tune a query that is taking too much time on a large
dataset (postgres 8.3).
SELECT DISTINCT
role_user.project_id AS projectId,
sfuser.username AS adminUsername,
sfuser.full_name AS adminFullName
FROM
role_operation role_operation,
ro
ginal Message-
From: Shaun Thomas [mailto:stho...@peak6.com]
Sent: Friday, January 28, 2011 7:31 AM
To: Anne Rosset
Cc: pgsql-performance@postgresql.org
Subject: Re: FW: [PERFORM] Queries becoming slow under heavy load
On 01/27/2011 11:12 PM, Anne Rosset wrote:
> Thanks for your response.
>
mailto:scott.marl...@gmail.com]
Sent: Wednesday, January 26, 2011 8:19 PM
To: Anne Rosset
Cc: pgsql-performance@postgresql.org
Subject: Re: FW: [PERFORM] Queries becoming slow under heavy load
On Wed, Jan 26, 2011 at 9:04 AM, Anne Rosset wrote:
PLEASE post just the settings you changed. I'm
cesses in 'D' state.
Are we facing some serious db locking? What could lead to this?
(The box has 8G and 8 cores)
Thanks for any help,
Anne
-Original Message-
From: Andy Colson [mailto:a...@squeakycode.net]
Sent: Tuesday, January 25, 2011 2:13 PM
To: Anne Rosset
Cc: pgs
Hi,
We are running some performances tests. With a lot of concurrent
access, queries get very slow. When there is no load, those queries run
fast.
We kind of see a trend about these queries: it seems like the ones that
become very slow have an ORDER BY or MAX in them.
Here are our config s
Joe Conway wrote:
On 06/10/2010 01:21 PM, Anne Rosset wrote:
I tried that and it didn't make any difference. Same query plan.
A little experimentation suggests this might work:
create index item_rank_project on item_rank(project_id, rank) where
pf_id IS NULL;
Joe
Joe Conway wrote:
On 06/10/2010 01:10 PM, Joe Conway wrote:
try:
create index item_rank_null_idx on item_rank(pf_id)
where rank IS NOT NULL AND pf_id IS NULL;
oops -- that probably should be:
create index item_rank_null_idx on item_rank(project_id)
where rank IS NOT NULL AND pf_id IS
Craig James wrote:
On 6/10/10 12:34 PM, Anne Rosset wrote:
Jochen Erwied wrote:
Thursday, June 10, 2010, 8:36:08 PM you wrote:
psrdb=# (SELECT
psrdb(# MAX(item_rank.rank) AS maxRank
psrdb(# FROM
psrdb(# item_rank item_rank
psrdb(# WHERE
psrdb(# item_rank.project_id='proj2783'
p
Kenneth Marshall wrote:
On Thu, Jun 10, 2010 at 12:34:07PM -0700, Anne Rosset wrote:
Jochen Erwied wrote:
Thursday, June 10, 2010, 8:36:08 PM you wrote:
psrdb=# (SELECT
psrdb(#MAX(item_rank.rank) AS maxRank
psrdb(# FROM
psrdb(#item_rank item_rank
psrdb
Heikki Linnakangas wrote:
On 10/06/10 22:47, Craig James wrote:
Postgres normally doesn't index NULL values even if the column is
indexed, so it has to do a table scan when your query includes an IS
NULL condition.
That was addressed in version 8.3. 8.3 and upwards can use an index
for IS NUL
Jochen Erwied wrote:
Thursday, June 10, 2010, 9:34:07 PM you wrote:
Time: 1.516 ms
Time: 13.177 ms
I'd suppose the first query to scan a lot less rows than the second one.
Could you supply an explained plan for the fast query?
Hi Jochen,
Here is the explained plan fo
Jochen Erwied wrote:
Thursday, June 10, 2010, 8:36:08 PM you wrote:
psrdb=# (SELECT
psrdb(#MAX(item_rank.rank) AS maxRank
psrdb(# FROM
psrdb(#item_rank item_rank
psrdb(# WHERE
psrdb(#item_rank.project_id='proj2783'
psrdb(# AND item_rank.pf_id IS NULL
psrdb(#
p
Jesper Krogh wrote:
On 2010-06-10 19:50, Anne Rosset wrote:
Any advice on how to make it run faster?
What timing do you get if you run it with \t (timing on) and without
explain analyze ?
I would be surprised if you can get it much faster than what is is.. I
may be that a
significant
Hi,
I have the following query that needs tuning:
psrdb=# explain analyze (SELECT
psrdb(#MAX(item_rank.rank) AS maxRank
psrdb(# FROM
psrdb(#item_rank item_rank
psrdb(# WHERE
psrdb(#item_rank.project_id='proj2783'
psrdb(# AND item_rank.pf_id IS NULL
psrdb(#
psrdb(#
Robert Haas wrote:
On Mon, Jun 1, 2009 at 4:53 PM, Anne Rosset wrote:
On Mon, Jun 1, 2009 at 2:14 PM, Anne Rosset wrote:
SELECT SUM(1) FROM item WHERE is_deleted = 'f'; sum - 1824592 (1
row)
SELECT SUM(1) FROM item WHERE folder_id = 'tracker3641
'; su
Dave Dutcher wrote:
-Original Message-
From: Anne Rosset
Subject: Re: [PERFORM] Unexpected query plan results
SELECT SUM(1) FROM item WHERE is_deleted = 'f'; sum
- 1824592
(1
row)
SELECT SUM(1) FROM item WHERE folder_id = 'trac
Robert Haas wrote:
On Mon, Jun 1, 2009 at 2:14 PM, Anne Rosset wrote:
The table has 468173 rows and the value for default_statistics_target is
750.
Anne
Hi Robert,
we did a vacuum analyze and the results are the same.
Here are the results of the queries :
SELECT SUM(1) FROM item
Robert Haas wrote:
On Fri, May 29, 2009 at 5:57 PM, Anne Rosset wrote:
Robert Haas wrote:
On Thu, May 28, 2009 at 6:46 PM, Anne Rosset wrote:
-> Index Scan using
item_pk on item (cost=0.00..176865.31 rows=97498 width
Robert Haas wrote:
On Thu, May 28, 2009 at 6:46 PM, Anne Rosset wrote:
-> Index Scan using
item_pk on item (cost=0.00..176865.31 rows=97498 width=88) (actual
time=117.304..2405.060 rows=71 loop
Dave Dutcher wrote:
From: Anne Rosset
Subject: Re: [PERFORM] Unexpected query plan results
Thank Dave. We are using postgresql-server-8.2.4-1PGDG and
have work-mem set to 20MB.
What value would you advise?
thanks,
Anne
Work-mem is kind of tricky because the right
Dave Dutcher wrote:
From: Anne Rosset
Subject: [PERFORM] Unexpected query plan results
Hi,
We have one query which has a left join. If we run this query without
the left join, it runs slower than with the left join.
[snip]
I am having a hard time to understand why the query runs
Hi,
We have one query which has a left join. If we run this query without
the left join, it runs slower than with the left join.
-query with the left join:
EXPLAIN ANALYZE
SELECT
artifact.id AS id,
artifact.priority AS priority,
item.title AS title,
item.name AS name,
field_value2.value AS s
Robert Haas wrote:
On Mon, Mar 23, 2009 at 1:08 PM, Anne Rosset wrote:
enable_nestloop = off
That may be the source of your problem. Generally setting enable_* to
off is a debugging tool, not something you ever want to do in
production.
...Robert
Thanks Robert. It seems to
Tom Lane wrote:
Robert Haas writes:
On Fri, Mar 20, 2009 at 1:16 PM, Anne Rosset wrote:
The db version is 8.2.4
Something is wrong here. How can setting enable_seqscan to off result
in a plan with a far lower estimated cost than the original plan?
Planner bug no
Alvaro Herrera wrote:
Robert Haas escribió:
Something is wrong here. How can setting enable_seqscan to off result
in a plan with a far lower estimated cost than the original plan? If
the planner thought the non-seq-scan plan is cheaper, it would have
picked that one to begin with.
Richard Huxton wrote:
Anne Rosset wrote:
EXPLAIN ANALYZE
SELECT
audit_change.id AS id,
audit_change.audit_entry_id AS auditEntryId,
audit_entry.object_id AS objectId,
audit_change.property_name AS propertyName,
audit_change.property_type AS propertyType
Hi,
We have the following 2 tables:
\d audit_change
Table "public.audit_change"
Column | Type | Modifiers
++---
id | character varying(32) | not null
audit_entry_id | character varying(32) |
...
In
40 matches
Mail list logo
