From: | Ivan Voras <ivoras(at)freebsd(dot)org> |
---|---|
To: | Ondrej Ivanič <ondrej(dot)ivanic(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Versioned, chunked documents |
Date: | 2012-04-01 23:05:58 |
Message-ID: | CAF-QHFUpeG+NEe0b4avpTXKbCPmPNn-dNDLK-xzkMwhPXWhb=w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2012/4/2 Ondrej Ivanič <ondrej(dot)ivanic(at)gmail(dot)com>:
> Hi,
>
> On 2 April 2012 08:38, Ivan Voras <ivoras(at)freebsd(dot)org> wrote:
>> db=> set enable_seqscan to off;
>
> <snip>
>
>>
>> This huge cost of 10000000000 which appeared out of nowhere in the
>> EXPLAIN output and the seq scan worry me - where did that come from?
>
> It is not possible to disable seq scan completely. The "enable_seqscan
> to off" just sets cost of this operation extremely high (10 000 000
> 000) thus planner is forced look for better plan. In your case planner
> wasn't able to find anything better hence
> cost=10000000009.55..10000000009.56.
Hi,
Thanks, I suspected something hard-coded might be adding to the cost,
but this leaves the more important issue: why is a seq scan happening
at all with an indexed field (the "id")?
If I read the EXPLAIN output (at http://explain.depesz.com/s/mpY)
correctly, this is where it happens:
Hash Cond: ((max(public.documents_chunks.id)) = public.documents_chunks.id)
The left hand side is a result of the MAX aggregate with a GROUP, but
the number of records is really small so I think the index should be
used on the right hand side of the hash cond.
From | Date | Subject | |
---|---|---|---|
Next Message | Martin Gregorie | 2012-04-01 23:22:02 | Re: Versioned, chunked documents |
Previous Message | Ondrej Ivanič | 2012-04-01 22:58:43 | Re: Versioned, chunked documents |