From: | Michael Olivier <molivier(at)yahoo(dot)com> |
---|---|
To: | Herouth Maoz <herouth(at)oumail(dot)openu(dot)ac(dot)il>, "pgsql-sql postgresql(dot)org" <pgsql-sql(at)postgreSQL(dot)org> |
Subject: | Re: [SQL] optimizing 2-table join w/millions of rows |
Date: | 1998-11-23 03:05:14 |
Message-ID: | 19981123030514.15338.rocketmail@send106.yahoomail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
---Herouth Maoz <herouth(at)oumail(dot)openu(dot)ac(dot)il> wrote:
>
> At 4:26 +0200 on 20/11/98, Michael Olivier wrote:
>
>
> >
> > select U.acctname from usertest U, bgndtest B where
> > B.part_needed=3 and B.loc_needed=5 and
> > B.acctname=U.acctname and U.acctname in
> > (select acctname from usertest where part=2 and loc=3)
>
> Can you explain *verbally* what you meant to do here? It seems as if
the
> subselect is redundant.
It's not redundant, but an attempt to optimize the overall query
performance by using a subquery. What this does is compare two users
parameters against each other: "find all users who need part 3 and
need loc 5 and who have part 2 and loc 3"
> How about:
>
> SELECT U.acctname
> FROM usertest U, bgndtest B
> WHERE B.acctname = U.acctname
> AND B.part_needed=3 AND B.loc_needed=5
> AND U.part=2 AND U.loc=3;
Yes, that looks equivalent. My problem is this is too slow an
operation as I'm benchmarking it right now. And if I add less-than or
greater-than comparisons, the performance goes _way_ down from there.
How can I get the best performance out of this kind of operation?
Is there any way to force postgres to hold certain tables in memory
all the time? As I said, cost of memory isn't an issue, but
performance is.
thanks,
Michael
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Herouth Maoz | 1998-11-23 13:09:09 | Re: [SQL] optimizing 2-table join w/millions of rows |
Previous Message | sqyang | 1998-11-23 02:41:22 | optimization |