Re: [Fwd: query efficiency - Can I speed it up?]
От | ann hedley |
---|---|
Тема | Re: [Fwd: query efficiency - Can I speed it up?] |
Дата | |
Msg-id | 45C21FC5.7080305@ed.ac.uk обсуждение исходный текст |
Ответ на | Re: [Fwd: query efficiency - Can I speed it up?] (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-novice |
psql (PostgreSQL) 8.0.3 Thanks, I'll try an upgrade. Tom Lane wrote: > ann hedley <ann.hedley@ed.ac.uk> writes: > >> Can anyone tell me if/how I can speed up this query? >> > > Try a newer version of Postgres --- I think 8.1 is the first one that > can make decent use of that two-column index in this type of query. > Notice that in the plan, only the "go_term" column is being checked > in the index condition: > > >> -> Index Scan using gotcha_go_term_sp_id on gotcha >> (cost=0.00..46809.29 rows=232 width=32) >> Index Cond: ((gotcha.go_term)::text = >> ("outer".go_term)::text) >> Filter: (((spid)::text = 'ALP'::text) OR ((spid)::text = >> 'ASP'::text) OR ((spid)::text = 'DIP'::text) OR ((spid)::text = >> 'GPP'::text)) >> > > I take it from the enormous cost that there are going to be lots of rows > with the same go_term, and it's the spid filter that is cutting it down > to a reasonable number of rows ... but this plan is going to visit the > heap for every row matching go_term, because the planner isn't smart > enough to fold the OR'd restriction clause together with the join > clause to make an index condition. It applies it as a "filter" instead > which is way way slower in this situation. I can't tell exactly which > PG release you're using, but it's definitely older than 8.1. > > regards, tom lane > > -- Ann "In a world without walls and fences - who needs Windows and Gates ?" (unknown)
В списке pgsql-novice по дате отправления: