From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alessandro Baretta <a(dot)baretta(at)barettadeit(dot)com> |
Cc: | Matteo Beccati <php(at)beccati(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: 500x speed-down: Wrong query plan? |
Date: | 2006-01-09 18:56:50 |
Message-ID: | 6914.1136833010@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Alessandro Baretta <a(dot)baretta(at)barettadeit(dot)com> writes:
> Tom Lane wrote:
>> I'm curious to see how many rows the planner thinks this will produce,
>> and whether it will use the index or not.
> dmd-freerp-1-alex=# EXPLAIN ANALYZE SELECT * FROM articolo WHERE
> articolo.xdbs_modified > '2006-01-08 18:25:00+01';
> QUERY PLAN
> -------------------------------------------------------------------------------------------------------------------------------------------
> Index Scan using articolo_modified_index on articolo (cost=0.00..3914.91
> rows=17697 width=653) (actual time=0.032..0.032 rows=0 loops=1)
> Index Cond: (xdbs_modified > '2006-01-08 18:25:00'::timestamp without time zone)
> Total runtime: 0.150 ms
> (3 rows)
Well, there's your problem: 17697 rows estimated vs 0 actual. With a
closer row estimate it would've probably done the right thing for the
join problem.
How many rows are really in the table, anyway? Could we see the
pg_stats row for articolo.xdbs_modified?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Luke Lonergan | 2006-01-09 19:01:43 | Re: help tuning queries on large database |
Previous Message | Chris Hoover | 2006-01-09 18:54:48 | Memory Usage Question |