To: =?iso-8859-1?Q?Andr=E9?= Volpato <andre.volpato@ecomtecnologia.com.br>
Cc: <pgsql-performance@postgresql.org>
Subject: Re: Postgres not using array
In-Reply-To: <48ADCA78.2090605@ecomtecnologia.com.br> (=?iso-8859-1?Q?=22A?=
	=?iso-8859-1?Q?ndr=E9?= Volpato"'s message of "Thu\,
	21 Aug 2008 17\:05\:12 -0300")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <48AC8292.5000708@ecomtecnologia.com.br>
	<48AD735D.6040403@ecomtecnologia.com.br>
	<23465.1219328880@sss.pgh.pa.us>
	<48AD80FA.30100@ecomtecnologia.com.br>
	<29595.1219345818@sss.pgh.pa.us>
	<48ADCA78.2090605@ecomtecnologia.com.br>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Fri, 22 Aug 2008 11:28:58 +0100
Message-ID: <87myj5jqc5.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Andr=E9 Volpato <andre.volpato@ecomtecnologia.com.br> writes:

> Tom Lane escreveu:
>>> We are guessing that a dual core 3.0GHz will beat up a quad core 2.2,
>>> at least in this environmnent with less than 4 concurrent queryes.
>>
>> The most you could hope for from that is less than a 50% speedup.  I'd
>> suggest investing some tuning effort first.  Some rethinking of your
>> schema, for example, might buy you orders of magnitude ... with no new
>> hardware investment.
>
> I think we almost reached the tuning limit, without changing the schema.

It's hard to tell from the plan you posted (and with only a brief look) but=
 it
looks to me like your query with that function is basically doing a join but
because the inner side of the join is in your function's index lookup it's
effectively forcing the use of a "nested loop" join. That's usually a good
choice for small queries against big tables but if you're joining a lot of
data there are other join types which are much faster. You might find the
planner can do a better job if you write your query as a plain SQL query and
let the optimizer figure out the best way instead of forcing its hand.


--=20
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's On-Demand Production Tuning