From: Mindaugas <ml@kilimas.com>
To: pgsql-performance@postgresql.org
Subject: Re: Dealing with big tables
Date: Sun, 02 Dec 2007 13:37:56 +0200 (EET)
Message-ID: <E1Iyn92-00056Z-So@fenris.runbox.com> (raw)
In-Reply-To: <1196593535.7946.8.camel@whiteair>
References: <E1Iym1h-0004Tg-VQ@garm.runbox.com>
<1196593535.7946.8.camel@whiteair>
> my answer may be out of topic since you might be looking for a
> postgres-only solution.. But just in case....
I'd like to stay with SQL.
> What are you trying to achieve exactly ? Is there any way you could
> re-work your algorithms to avoid selects and use a sequential scan
> (consider your postgres data as one big file) to retrieve each of the
> rows, analyze / compute them (possibly in a distributed manner), and
> join the results at the end ?
I'm trying to improve performance - get answer from mentioned query
faster.
And since cardinality is high (100000+ different values) I doubt that it
would be possible to reach select speed with reasonable number of nodes of
sequential scan nodes.
Mindaugas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: ml@kilimas.com
Subject: Re: Dealing with big tables
In-Reply-To: <E1Iyn92-00056Z-So@fenris.runbox.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox