Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id F099765003C for ; Sat, 5 Jul 2008 09:02:24 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 28398-08 for ; Sat, 5 Jul 2008 09:02:16 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.184]) by postgresql.org (Postfix) with ESMTP id 3D7EB64FD42 for ; Sat, 5 Jul 2008 09:02:20 -0300 (ADT) Received: by mu-out-0910.google.com with SMTP id i2so423631mue.3 for ; Sat, 05 Jul 2008 05:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=fSrOCUtJIfpDb2eyXfOAhiMB7edKwBTC4ozs00U0Tu8=; b=BYc3eDDOhj3aEm3dLv023rtOGkQHGl63v4DOsWAg1dxk5sO5c4mzpWZSjBbnVOTe2r TjS08eTslN0WyUER2wlxsF0YRkkbz2UdmjmBoTAlSIww6xlo3j5skQ3oS77qoXJ0kt28 tbeI148soZD/c8derxHvHCwPFyWXWuHo3mTBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=gmhW5Wtg7RZ8ZaFTyG9NsiteLpChGs9NNCDH1ASgYNSuKk8cGJAuJnig5UQUKpTITo NN95vx0SID6trqzoWnQ2HD3E3THpy0VWNElmvigudJy+2Fd6NEH8iMlooRtwuJQ+XgzV 1olDbsG2hOHTmlJTlWh1CXxOSus/shyYcW8iQ= Received: by 10.102.253.6 with SMTP id a6mr862829mui.92.1215259338528; Sat, 05 Jul 2008 05:02:18 -0700 (PDT) Received: by 10.103.134.13 with HTTP; Sat, 5 Jul 2008 05:02:18 -0700 (PDT) Message-ID: <15aa6b3e0807050502u463c336bva783927eed2e7e89@mail.gmail.com> Date: Sat, 5 Jul 2008 09:02:18 -0300 From: "Sergio Gabriel Rodriguez" To: "Rusty Conover" Subject: Re: Subquery WHERE IN or WHERE EXISTS faster? Cc: Ulrich , pgsql-performance@postgresql.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48665741.2060900@gmx.net> <29009.1214668423@sss.pgh.pa.us> <4866B624.1090906@gmx.net> <48688B44.6070407@gmx.net> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200807/52 X-Sequence-Number: 30652 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, 2008 at 4:44 AM, Rusty Conover wrote: > > 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 me, because I am only running a very small server >> with 256MB RAM and the webserver also likes to use some RAM. >> >> Does Postgre cache the HASH-Table for later use? For example when the user >> reloads the website. >> > > No the hash table only lives as long as the query is being executed. If > you're looking for generic caching, I'd suggest memcached may be able to > fill your needs. > > Cheers, > > Rusty > -- > Rusty Conover > InfoGears Inc. > http://www.infogears.com > > > > > > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance >