FYI, raising cpu_tuple_cost from 0.01 to 0.5 fixed the problem..!
On 04/05/2012 14:43, Julien Cigar wrote:
Hi Mario,
Setting it to > -1, or even removing the condition doesn't change
anything .. the problem is more that the estimate of the join point
sucks pretty much ..
Julien
On 04/05/20
Hi Mario,
Setting it to > -1, or even removing the condition doesn't change
anything .. the problem is more that the estimate of the join point
sucks pretty much ..
Julien
On 04/05/2012 14:32, Mario Dankoor wrote:
Julien,
I generally try avoid NOT predicates.
If your geo_id is an integer,
Julien,
I generally try avoid NOT predicates.
If your geo_id is an integer, try geo_id > -1
or if it's a varchar geo_id > ''.
The idea is that geo_id > 0 is false for null values.
I don't think query optimizers are fond of NOT predicates.
SELECT t_geo.frequence
,ST_SetSRID(gc.geom, 432
Hello Mario,
The query is in the pastie.org links, here is a copy:
SELECT
t_geo.frequence, ST_SetSRID(gc.geom, 4326) as geom
FROM (
SELECT
geo_id , count(*) AS frequence
FROM
hit.context_to_context_links
WHERE
NOT geo_id IS NULL ANDtaxon_id= ANY (
SELECT
taxon_id
Julien,
It looks like you forgot to post the query.
Mario
On 2012-04-05 1:38 PM, Julien Cigar wrote:
Hello,
I have an extremely bad plan for one of my colleague's query.
Basically PostgreSQL chooses to seq scan instead of index scan. This
is on:
antabif=# select version();
Hello,
I have an extremely bad plan for one of my colleague's query. Basically
PostgreSQL chooses to seq scan instead of index scan. This is on:
antabif=# select version();
version
