Re: Cost of sort/order by not estimated by the query planner

From: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
To: Laurent Laborde <kerdezixe(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cost of sort/order by not estimated by the query planner
Date: 2009-12-03 06:58:39
Message-ID: e08cc0400912022258mdb775fdp618f872c82f7276d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

2009/12/1 Laurent Laborde <kerdezixe(at)gmail(dot)com>:
> The problem is in the order by, of course.
> If i remove the "order by" the LIMIT 5 is faster (0.044 ms) and do an
> index scan.
> At limit 500 (without order) it still use an index scan and it is
> slightly slower.
> At limit 5000 (without order) it switch to a Bitmap Index Scan +
> Bitmap Heap Scan and it's slower but acceptable (5.275 ms)
>
> Why, with the "QUERY 2", postgresql doesn't estimate the cost of the
> Sort/ORDER BY ?
> Of course, by ignoring the order, both query plan are right and the
> choice for thoses differents plans totally make sense.

It's because the result of IndexScan is already sorted by demanded
key, whereas the one of BitmapIndexScan isn't. But I'm not sure why
the query lasts more than 30 minutes...

Regards,

--
Hitoshi Harada

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Itagaki Takahiro 2009-12-03 07:05:47 Re: ProcessUtility_hook
Previous Message Craig Ringer 2009-12-03 05:35:23 Re: [Bacula-users] Catastrophic changes to PostgreSQL 8.4

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2009-12-03 07:04:01 Re: Checkpoint spikes
Previous Message Richard Neill 2009-12-03 06:23:12 Re: Analyse without locking?