Re: Versioned, chunked documents
От
Ivan Voras
Тема
Re: Versioned, chunked documents
Дата
Msg-id
CAF-QHFUpeG+NEe0b4avpTXKbCPmPNn-dNDLK-xzkMwhPXWhb=w@mail.gmail.com
Ответ на
Re: Versioned, chunked documents (Ondrej Ivanič)
Список
Дерево обсуждения
Versioned, chunked documents Ivan Voras <ivoras@freebsd.org>
Re: Versioned, chunked documents Martin Gregorie <martin@gregorie.org>
Re: Versioned, chunked documents Martin Gregorie <martin@gregorie.org>
Re: Versioned, chunked documents Ivan Voras <ivoras@freebsd.org>
Re: Versioned, chunked documents Ondrej Ivanič <ondrej.ivanic@gmail.com>
Re: Versioned, chunked documents Ivan Voras <ivoras@freebsd.org>
2012/4/2 Ondrej Ivanič : > Hi, > > On 2 April 2012 08:38, Ivan Voras wrote: >> db=> set enable_seqscan to off; > > > >> >> 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.
В списке pgsql-general по дате отправления