The query plan from your suggestion with regular expression is
Unique (cost=318.24 size=0 width=0)
-> Sort (cost=318.24 size=0 width=0)
-> Hash Join (cost=318.24 size=409 width=292)
-> Nested Loop (cost=310.65 size=131 width=268)
-> Seq Scan on clients (cost=126.07 size=87 width=256)
-> Index Scan using idxsclientidid1 on sotrud (cost=2.12 size=2271 width=12)
-> Hash (cost=0.00 size=0 width=0)
-> Seq Scan on prinadleg (cost=1.13 size=4 width=24)
It's look good, but it's better for our development team to have a simple query with 'OR'.
Unfortunely it's not better for Postgres optimizer. ;)
May be we try to istall an test Postgres v.6.5.1.
Thanks for your help, Natalya.
At 16:00 +0200 on 08/09/1999, Natalya S. Makushina wrote:
> i tried your query.
> This is query plan for select with union clause
> NOTICE: QUERY PLAN:
>...
> I think that it is too slow.
> May be optimizer is more intellect in Postgres v.6.5.1?
> I use Postgres v.6.4.2.
Yes, it's definitely supposed to be better.
By the way, if there are not supposed to be overlaps in the queries (that
is, a query about one email will never return the same tuple that was
returned by a query about another email), you should try UNION ALL. I think
it should remove the unique phases.
By the way, did you try the suggestion with the regular expression? What
was the cost of that?
Herouth
--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma