2009/6/2 Robert Haas robertmh...@gmail.com
On Mon, Jun 1, 2009 at 4:53 PM, Anne Rosset aros...@collab.net wrote:
On Mon, Jun 1, 2009 at 2:14 PM, Anne Rosset aros...@collab.net wrote:
SELECT SUM(1) FROM item WHERE is_deleted = 'f'; sum - 1824592
(1
row)
SELECT SUM(1) FROM item
On Jun 2, 2009, at 6:20 AM, Віталій Тимчишин
tiv...@gmail.com wrote:
2009/6/2 Robert Haas robertmh...@gmail.com
On Mon, Jun 1, 2009 at 4:53 PM, Anne Rosset aros...@collab.net
wrote:
On Mon, Jun 1, 2009 at 2:14 PM, Anne Rosset aros...@collab.net
wrote:
SELECT SUM(1) FROM item WHERE
Robert Haas wrote:
On Mon, Jun 1, 2009 at 4:53 PM, Anne Rosset aros...@collab.net wrote:
On Mon, Jun 1, 2009 at 2:14 PM, Anne Rosset aros...@collab.net wrote:
SELECT SUM(1) FROM item WHERE is_deleted = 'f'; sum - 1824592 (1
row)
SELECT SUM(1) FROM item WHERE folder_id =
On Tue, Jun 2, 2009 at 11:16 AM, Anne Rosset aros...@collab.net wrote:
Thanks a lot Robert. Not sure how we will tackle this but at least now we
have an explanation. From what I read, results won't improved in 8.4. Is
that correct?
Yes, that's correct.
Good luck...
...Robert
--
Sent via
Robert Haas wrote:
On Fri, May 29, 2009 at 5:57 PM, Anne Rosset aros...@collab.net wrote:
Robert Haas wrote:
On Thu, May 28, 2009 at 6:46 PM, Anne Rosset aros...@collab.net wrote:
- Index Scan using
item_pk on item
On Mon, Jun 1, 2009 at 2:14 PM, Anne Rosset aros...@collab.net 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 WHERE
Robert Haas wrote:
On Mon, Jun 1, 2009 at 2:14 PM, Anne Rosset aros...@collab.net 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 :
-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 = 'tracker3641
/sf/sfmain/do/go/tracker3641?returnUrlKey
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 = 'tracker3641
/sf/sfmain/do/go
On Mon, Jun 1, 2009 at 4:53 PM, Anne Rosset aros...@collab.net wrote:
On Mon, Jun 1, 2009 at 2:14 PM, Anne Rosset aros...@collab.net wrote:
SELECT SUM(1) FROM item WHERE is_deleted = 'f'; sum - 1824592 (1
row)
SELECT SUM(1) FROM item WHERE folder_id = 'tracker3641
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
faster with the
left join
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
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 setting depends on how much ram
your
On Fri, May 29, 2009 at 1:30 PM, Dave Dutcher d...@tridecap.com 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
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
When the query plan takes a wrong path, is it possible that it is because
statistics have not been run or updated?
Yes. If you are not using autovacuum, you need to ANALYZE regularly,
or bad things will happen to you.
...Robert
--
Sent via pgsql-performance mailing list
Robert Haas wrote:
On Thu, May 28, 2009 at 6:46 PM, Anne Rosset aros...@collab.net 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 loops=1)
On Fri, May 29, 2009 at 5:57 PM, Anne Rosset aros...@collab.net wrote:
Robert Haas wrote:
On Thu, May 28, 2009 at 6:46 PM, Anne Rosset aros...@collab.net wrote:
- Index Scan using
item_pk on item (cost=0.00..176865.31 rows=97498 width=88)
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
19 matches
Mail list logo
