Re: [PATCH] Add a guc parameter to control limit clause adjust path cost.
| От | Tom Lane | 
|---|---|
| Тема | Re: [PATCH] Add a guc parameter to control limit clause adjust path cost. | 
| Дата | |
| Msg-id | 436366.1762105453@sss.pgh.pa.us обсуждение исходный текст  | 
		
| Ответ на | [PATCH] Add a guc parameter to control limit clause adjust path cost. ("Haiyang Li" <mohen.lhy@alibaba-inc.com>) | 
| Ответы | 
                	
            		Re: [PATCH] Add a guc parameter to control limit clause adjust path cost.
            		
            		 | 
		
| Список | pgsql-hackers | 
"Haiyang Li" <mohen.lhy@alibaba-inc.com> writes:
> To address this, I have added a GUC parameter to control the
> optimizer's use of LIMIT clauses for adjusting the cost of paths,
> providing a means to force intervention. We have also considered similar
> scenarios, such as MIN/MAX. Note that we still retain the optimizer's
> use of LIMIT clauses to adjust the number of rows, as this is always
> reasonable. The patch is provided in attachment(not add test case yet).
> Any thoughts?
I think this is a pretty bad solution as given.  A global GUC switch
is an extremely blunt instrument and hard to use in production without
breaking cases you didn't want to break.  The proposed patch seems to
have that problem in spades, as it looks like you've turned off
*every* place that has any consideration of LIMIT effects without
concern for whether that place is known to have problems, and
furthermore done so at the greatest possible distance from where the
estimates actually get made.
We have discussed fixes with a bit more finesse, such as adjusting
LIMIT cost estimates with the understanding that the tuples being
sought may not be uniformly distributed in the input data (which is
usually the ultimate cause of such plans performing badly).  Nobody's
carried such ideas through to a complete proposal as yet, though.
            regards, tom lane
		
	В списке pgsql-hackers по дате отправления: