From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "nicky" <nicky(at)valuecare(dot)nl>, "Sven Geisler" <sgeisler(at)aeccom(dot)com> |
Cc: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Speeding up query, Joining 55mil and 43mil records. |
Date: | 2006-06-22 12:17:29 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCEA0FA74@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> PostgreSQL elects not to use them. I assume, because it most
> likely needs to traverse the entire table anyway.
>
> if i change: / substr(t0.code,1,2) not in
> ('14','15','16','17')/
> to (removing the NOT): / substr(t0.code,1,2) in
> ('14','15','16','17')/
>
> it uses the index, but it's not the query that needs to be
> run anymore.
If this is the only query that you're having problems with, you might be
helped with a partial index - depending on how much 14-17 really
filters. Try something like:
CREATE INDEX foo ON src.src_faktuur_verrsec (id) WHERE
substr(t0.code,1,2) not in ('14','15','16','17') AND
(substr(t0.correctie,4,1) <> '1' OR t0.correctie is null)
That index shuold be usable for the JOIN while filtering out all the
unnecessary rows before you even get tehre.
In the same way, if it filters a lot of rows, you might want to try
CREATE INDEX foo ON src.src_faktuur_verricht (id) WHERE EXTRACT(YEAR
from t1.datum) > 2004
But this kind of requires that the partial indexes actually drop
significant amounts of the table. If not, then they'll be of no help.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Sven Geisler | 2006-06-22 12:19:58 | Re: Speeding up query, Joining 55mil and 43mil records. |
Previous Message | nicky | 2006-06-22 12:10:50 | Re: Speeding up query, Joining 55mil and 43mil records. |