| From: | "Mindaugas" <ml(at)kilimas(dot)com> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Dealing with big tables |
| Date: | 2007-12-02 11:37:56 |
| Message-ID: | E1Iyn92-00056Z-So@fenris.runbox.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guillaume Smet | 2007-12-02 11:55:34 | Re: Dealing with big tables |
| Previous Message | Sami Dalouche | 2007-12-02 11:05:35 | Re: Dealing with big tables |