Re: Query hangs when getting too complex... - Mailing list pgsql-general
From | Paulo Jan |
---|---|
Subject | Re: Query hangs when getting too complex... |
Date | |
Msg-id | 3C20AF65.AD2C0996@digital.ddnet.es Whole thread Raw |
In response to | Re: Query hangs when getting too complex... (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
List | pgsql-general |
Stephan Szabo wrote: > > > SELECT count(idarchivo) FROM archivos WHERE > > revision <= 3 AND (EXISTS > > (SELECT idarchivo FROM archivos_fulltext_en WHERE revision <= 3 > > AND archivos_fulltext_en.idarchivo=archivos.idarchivo > > AND LOWER(TRANSLATE(archivos_fulltext_en.title || > > archivos_fulltext_en.description || archivos_fulltext_en.place || > > archivos_fulltext_en.province || archivos_fulltext_en.state || > > archivos_fulltext_en.country || archivos_fulltext_en.race || > > archivos_fulltext_en.sex || archivos_fulltext_en.class || > > archivos_fulltext_en.tesauro_en, '[áéíóúÁÉÍÓÚ]', '[aeiouAEIOU]')) LIKE > > '%actress%')) > > AND idsexo=2 AND archivos.joven = 1 AND posado=1 > > AND fechafoto BETWEEN '01/1/1976' AND '19/12/2001' > > That's wierd. What does explain show for the query? > Oh, yes, I forgot *that* one: covermaster=# explain SELECT count(idarchivo) FROM archivos WHERE revision <= 3 AND (EXISTS (SELECT idarchivo FROM archivos_fulltext_en WHERE revision <= 3 AND archivos_fulltext_en.idarchivo=archivos.idarchivo AND LOWER(TRANSLATE(archivos_fulltext_en.title || archivos_fulltext_en.description || archivos_fulltext_en.place || archivos_fulltext_en.province || archivos_fulltext_en.state || archivos_fulltext_en.country || archivos_fulltext_en.race || archivos_fulltext_en.sex || archivos_fulltext_en.class || archivos_fulltext_en.tesauro_en, '[áéíóúÁÉÍÓÚ]', '[aeiouAEIOU]')) LIKE '%politic%')) AND idsexo=2 AND archivos.joven = 1 AND posado=1 AND fechafoto BETWEEN '01/1/1976' AND '19/12/2001'; NOTICE: QUERY PLAN: Aggregate (cost=15.59..15.59 rows=1 width=4) -> Index Scan using archivos_idx_1 on archivos (cost=0.00..15.59 rows=1 width=4) SubPlan -> Index Scan using archivos_fulltext_en_idx_1 on archivos_fulltext_en (cost=0.00..2.06 rows=1 width=4) "archivos_idx_1" is an index on the "revision" column of "archivos", while "archivos_fulltext_en_idx_1" is an index on archivos_fulltext_en.idarchivo. If I take out one condition of the above query, say "idsexo=2", EXPLAIN shows: covermaster=# explain SELECT count(idarchivo) FROM archivos WHERE revision <= 3 AND (EXISTS (SELECT idarchivo FROM archivos_fulltext_en WHERE revision <= 3 AND archivos_fulltext_en.idarchivo=archivos.idarchivo AND LOWER(TRANSLATE(archivos_fulltext_en.title || archivos_fulltext_en.description || archivos_fulltext_en.place || archivos_fulltext_en.province || archivos_fulltext_en.state || archivos_fulltext_en.country || archivos_fulltext_en.race || archivos_fulltext_en.sex || archivos_fulltext_en.class || archivos_fulltext_en.tesauro_en, '[áéíóúÁÉÍÓÚ]', '[aeiouAEIOU]')) LIKE '%politic%')) AND archivos.joven = 1 AND posado=1 AND fechafoto BETWEEN '01/1/1976' AND '19/12/2001'; NOTICE: QUERY PLAN: Aggregate (cost=15.58..15.58 rows=1 width=4) -> Index Scan using archivos_idx_1 on archivos (cost=0.00..15.58 rows=1 width=4) SubPlan -> Index Scan using archivos_fulltext_en_idx_1 on archivos_fulltext_en (cost=0.00..2.06 rows=1 width=4) Any ideas? Personally, I don't see anything odd here (other than the fact that there's nothing odd <g>). > As an additional note, I don't think the query above does what you want in > any case unless there are delimiters at the beginings or end of the > strings you're concatenating, and if any of the strings is null the result > of the concatenation is null. (Imagine that description ends in act and > place starts with ress for example) I'm aware of these... erm, "additional factors", and they are accounted for. Paulo Jan. DDnet.
pgsql-general by date: