| From: | Nis Jørgensen <nis(at)superlativ(dot)dk> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Seqscan |
| Date: | 2007-10-23 13:36:21 |
| Message-ID: | ffktcs$sbk$1@ger.gmane.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
(Please don't top-post. )
Adrian Demaestri skrev:
> */Jeff Davis <pgsql(at)j-davis(dot)com>/* escribió:
>
> On Mon, 2007-10-22 at 19:24 -0700, Adrian Demaestri wrote:
> > Hi,
> > I think planner should use other plans than seqscan to solve querys
> > like select * from hugetable limit 1, especially when the talbe is
> > very large. Is it solved in newer versions or is there some open
> > issues about it?.
> > thanks
> > I'm working with postgres 8.0.1,
>
> For the query in question, what would be faster than a seqscan? It
> doesn't read the whole table, it only reads until it satisfies the limit
> clause.
> It is not actualy a table, sorry, it is a quite complex view that
> involve three large tables.
If hugetable isn't a table, you chose a really bad name for it.
What you have here is a specific query performing badly, not a generic
issue with all queries containing "LIMIT X". You might of course have
found a construct which the planner has problems with - but the first
step is to let us see the result of EXPLAIN ANALYZE.
Anyway, I think you might be hitting this issue:
"Fix mis-planning of queries with small LIMIT values due to poorly
thought out "fuzzy" cost comparison"
(http://www.postgresql.org/docs/8.0/static/release-8-0-4.html)
which was fixed in 8.0.4 . You should upgrade.
Nis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ron St-Pierre | 2007-10-23 15:53:17 | 12 hour table vacuums |
| Previous Message | Adrian Demaestri | 2007-10-23 13:06:39 | Re: Seqscan |