Hi Ulrich, do you try with
SELECT p.speed FROM processor p
INNER JOIN users_processors up ON p.id=up.processorid
AND up.userid=1
?
Or your question is only about IN and EXIST?
regards,
Sergio Gabriel Rodriguez
Corrientes - Argentina
http://www.3trex.com.ar
On Sat, Jun 28,
Hi Ulrich, do you try with
SELECT p.speed FROM processor p
INNER JOIN users_processors up ON p.id=up.processorid
AND up.userid=1
?
Or your question is only about IN and EXIST?
regards,
Sergio Gabriel Rodriguez
Corrientes - Argentina
http://www.3trex.com.ar
On Mon, Jun 30,
On Jun 30, 2008, at 1:29 AM, Ulrich wrote:
I think it will be fast, because the "IN set", which is the result
of "SELECT processorid FROM users_processors WHERE userid=4040", is
limited to a maximum of ~500 processors which is not very big.
Increasing Postgres' RAM would be difficult for m
I think it will be fast, because the "IN set", which is the result of
"SELECT processorid FROM users_processors WHERE userid=4040", is limited
to a maximum of ~500 processors which is not very big. Increasing
Postgres' RAM would be difficult for me, because I am only running a
very small server
On Jun 28, 2008, at 4:07 PM, Ulrich wrote:
Hi,
I have added a bit of dummy Data, 10 processors, 1 users,
each user got around 12 processors.
I have tested both queries. First of all, I was surprised that it is
that fast :) Here are the results:
EXPLAIN ANALYZE SELECT speed FRO
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> i've made some queries run faster using EXISTS instead of large IN
> clauses... actually, it was NOT EXISTS replacing a NOT IN
That's just about entirely unrelated ...
regards, tom lane
--
Sent via pgsql-performance mailing
On Sat, Jun 28, 2008 at 10:53 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Ulrich <[EMAIL PROTECTED]> writes:
>> People say that [EXISTS is faster]
>
> People who say that are not reliable authorities, at least as far as
> Postgres is concerned. But it is always a bad idea to extrapolate
> results on
"Ulrich" <[EMAIL PROTECTED]> writes:
> Hi,
> Yes that looks strange. But it is not possible that I have processors in
> "users_processors" which do not appear in "processors", because
> "users_processors" contains foreign keys to "processors".
>
> If I remove the LIMIT 10 OFFSET 1 the line "Sort (
Hi,
Yes that looks strange. But it is not possible that I have processors in
"users_processors" which do not appear in "processors", because
"users_processors" contains foreign keys to "processors".
If I remove the LIMIT 10 OFFSET 1 the line "Sort (cost= rows=11.."
disappears and the quer
"Ulrich" <[EMAIL PROTECTED]> writes:
> EXPLAIN ANALYZE SELECT speed FROM processors WHERE id IN (SELECT processorid
> FROM users_processors WHERE userid=4040) ORDER BY speed ASC LIMIT 10 OFFSET 1;
>
> Limit (cost=113.73..113.75 rows=7 width=5) (actual time=0.335..0.340 rows=10
> loops=1)
> ->
Hi,
I have added a bit of dummy Data, 10 processors, 1 users, each
user got around 12 processors.
I have tested both queries. First of all, I was surprised that it is
that fast :) Here are the results:
EXPLAIN ANALYZE SELECT speed FROM processors WHERE id IN (SELECT
processorid FRO
Ulrich <[EMAIL PROTECTED]> writes:
> People say that [EXISTS is faster]
People who say that are not reliable authorities, at least as far as
Postgres is concerned. But it is always a bad idea to extrapolate
results on toy tables to large tables --- quite aside from measurement
noise and caching i
Hi,
I am new to SQL and have two tables..., "processor" and
"users_processors". The first table contains Processors:
CREATE TABLE processor (
id SERIAL,
speed varchar(50) NOT NULL,
type int2 NOT NULL,
PRIMARY KEY (id)
);
CREATE UNIQUE INDEX processor_speed_index ON processors(lower(speed));
E
13 matches
Mail list logo
