Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
From: "Mindaugas" <ml@kilimas.com>
To: pgsql-performance@postgresql.org
Subject: Re: Dealing with big tables
Date: Sun, 02 Dec 2007 14:35:45 +0200 (EET)
References: <E1Iym1h-0004Tg-VQ@garm.runbox.com>
	<87r6i5gv06.fsf@oxford.xeocode.com>
In-Reply-To: <87r6i5gv06.fsf@oxford.xeocode.com>
Message-Id: <E1Iyo2z-00055w-E1@fenris.runbox.com>


> What exactly is your goal? Do you need this query to respond in under a
> specific limit? What limit? Do you need to be able to execute many instan=
ces
> of this query in less than 5s * the number of executions? Or do you have =
more
> complex queries that you're really worried about?

  I'd like this query to respond under a specific time limit. 5s now is OK =
but 50s later for 10000 rows is too slow.

> Both Greenplum and EnterpriseDB have products in this space which let you
> break the query up over several servers but at least in EnterpriseDB's ca=
se
> it's targeted towards running complex queries which take longer than this=
 to
> run. I doubt you would see much benefit for a 5s query after the overhead=
 of
> sending parts of the query out to different machines and then reassemblin=
g the
> results. If your real concern is with more complex queries they may make =
sense
> though. It's also possible that paying someone to come look at your datab=
ase
> will find other ways to speed it up.

  I see. This query also should benefit alot even when run in parallel on o=
ne server. Since anyway most time it spends in waiting for storage to respo=
nd.

  Also off list I was pointed out about covering indexes in MySQL. But they=
 are not supported in PostgreSQL, aren't they?

  Mindaugas