On Thu, Mar 30, 2006 at 01:59:10PM +0200, Peter Eisentraut wrote:
EXPLAIN ANALYZE select activity_id from activity where state in (1,
10001)
order by activity_id limit 100;
QUERY PLAN
Limit (cost=0.00..622.72 rows=100 width=8) (actual
time=207356.054..207356.876 rows=100 loops=1)
On Thu, Mar 30, 2006 at 01:59:10PM +0200, Peter Eisentraut wrote:
The table has seen VACUUM FULL and REINDEX before this.
But no analyze?
Mike Stone
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
Am Donnerstag, 30. März 2006 14:02 schrieb Steinar H. Gunderson:
On Thu, Mar 30, 2006 at 01:59:10PM +0200, Peter Eisentraut wrote:
EXPLAIN ANALYZE select activity_id from activity where state in (1,
10001) order by activity_id limit 100;
QUERY PLAN
Limit (cost=0.00..622.72
Am Donnerstag, 30. März 2006 14:06 schrieb Michael Stone:
On Thu, Mar 30, 2006 at 01:59:10PM +0200, Peter Eisentraut wrote:
The table has seen VACUUM FULL and REINDEX before this.
But no analyze?
ANALYZE as well, but the plan choice is not the point anyway.
--
Peter Eisentraut
On Thu, Mar 30, 2006 at 02:23:53PM +0200, Peter Eisentraut wrote:
EXPLAIN ANALYZE select activity_id from activity where state in (1,
10001) order by activity_id limit 100;
QUERY PLAN
Limit (cost=0.00..622.72 rows=100 width=8) (actual
time=207356.054..207356.876 rows=100 loops=1)
-
Hi, Peter,
Peter Eisentraut wrote:
The table has seen VACUUM FULL and REINDEX before this.
But no analyze?
ANALYZE as well, but the plan choice is not the point anyway.
Maybe you could add a combined Index on activity_id and state, or (if
you use this kind of query more often) a conditional
On Thu, Mar 30, 2006 at 02:31:34PM +0200, Steinar H. Gunderson wrote:
Well, it's logical enough; it scans along activity_id until it finds one with
state=1 or state=10001. You obviously have a _lot_ of records with low
activity_id and state none of these two, so Postgres needs to scan all
Am Donnerstag, 30. März 2006 14:31 schrieb Steinar H. Gunderson:
Well, it's logical enough; it scans along activity_id until it finds one
with state=1 or state=10001. You obviously have a _lot_ of records with
low activity_id and state none of these two, so Postgres needs to scan all
those
On Thu, Mar 30, 2006 at 02:59:02PM +0200, Peter Eisentraut wrote:
Well, it's logical enough; it scans along activity_id until it finds one
with state=1 or state=10001. You obviously have a _lot_ of records with
low activity_id and state none of these two, so Postgres needs to scan all
On Thu, Mar 30, 2006 at 02:51:47PM +0200, Steinar H. Gunderson wrote:
On Thu, Mar 30, 2006 at 07:42:53AM -0500, Michael Stone wrote:
Yes. And the estimates are bad enough (orders of magnitude) that I can't
help but wonder whether pg could come up with a better plan with better
statistics:
-
Michael Stone [EMAIL PROTECTED] writes:
Yes. I was looking at the other side; I thought pg could estimate how
much work it would have to do to hit the limit, but double-checking it
looks like it can't.
Yes, it does, you just have to understand how to interpret the EXPLAIN
output. Peter had
Tom Lane wrote:
The problem here appears to be a non-random correlation between state
and activity, such that the desired state values are not randomly
scattered in the activity sequence. The planner doesn't know about
that correlation and hence can't predict the poor startup time.
So from
Peter Eisentraut [EMAIL PROTECTED] writes:
So from when to when is the startup time (the x in x..y) actually
measured? When does the clock start ticking and when does it stop?
That is what's confusing me.
The planner thinks of the startup time (the first estimated-cost number)
as the time
13 matches
Mail list logo
