Re: Delete query takes exorbitant amount of time

Поиск
Список
Период
Сортировка
Искать
От
Simon Riggs
Тема
Re: Delete query takes exorbitant amount of time
Дата
Msg-id
1112122406.11750.1055.camel@localhost.localdomain
Ответ на
Список
Дерево обсуждения
Delete query takes exorbitant amount of time Karim Nassar <Karim.Nassar@acm.org>
Re: Delete query takes exorbitant amount of time Tom Lane <tgl@sss.pgh.pa.us>
Re: Delete query takes exorbitant amount of time Mark Lewis <mark.lewis@mir3.com>
Re: Delete query takes exorbitant amount of time Tom Lane <tgl@sss.pgh.pa.us>
Re: Delete query takes exorbitant amount of time Mark Lewis <mark.lewis@mir3.com>
Re: Delete query takes exorbitant amount of time Gaetano Mendola <mendola@bigfoot.com>
Re: Delete query takes exorbitant amount of time Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: Delete query takes exorbitant amount of time Oleg Bartunov <oleg@sai.msu.su>
Re: Delete query takes exorbitant amount of time Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: Delete query takes exorbitant amount of time Karim Nassar <karim.nassar@acm.org>
Re: Delete query takes exorbitant amount of time Josh Berkus <josh@agliodbs.com>
Re: Delete query takes exorbitant amount of time Karim Nassar <karim.nassar@NAU.EDU>
Re: Delete query takes exorbitant amount of time Josh Berkus <josh@agliodbs.com>
Re: Delete query takes exorbitant amount of time Simon Riggs <simon@2ndquadrant.com>
On Tue, 2005-03-29 at 12:31 -0500, Tom Lane wrote:
> Simon Riggs  writes:
> > That implies to me that LIMIT queries are not considered correctly in
> > the M&L formula and thus we are more likely to calculate a too-high cost
> > for using an index in those circumstances....and thus more likely to
> > SeqScan for medium sized relations?
> 
> You misunderstand how LIMIT is handled.  

Huh? Well, not this time. (Though my error rate is admittedly high.)

> The plan structure is
> 
> 	LIMIT ...
> 		regular plan ...
> 
> and so the strategy is to plan and cost the regular plan as though it
> would be carried out in full, and then take an appropriate fraction
> of that at the LIMIT stage.

To cost it as if it would be carried out in full and then not execute in
full is the same thing as saying it overestimates the actual execution
cost. Which can lead to selection of SeqScan plan when the IndexScan
would have been cheaper, all things considered.

...it could work like this

	LIMIT ....
		regular plan (plan chosen knowing that LIMIT follows)

so that the LIMIT would be considered in the M&L formula.

Not that I am driven by how other systems work, but both DB2 and Oracle
allow this form of optimization.

There's not a huge benefit in sending LIMIT 1 through on the FK check
queries unless they'd be taken into account in the planning.

Anyway, I'm not saying I know how to do this yet/ever, just to say it is
possible to use the information available to better effect.

This looks like a TODO item to me? Thoughts?

Best Regards, Simon Riggs

В списке pgsql-performance по дате отправления
От: Vinicius Bernardi
Дата:
Сообщение: Million of rows
От: Michael Fuhr
Дата:
Сообщение: Re: Million of rows
FAQ