Re: [PERFORM] Big IN() clauses etc : feature proposal
От | Markus Schaber |
---|---|
Тема | Re: [PERFORM] Big IN() clauses etc : feature proposal |
Дата | |
Msg-id | 4461EAAC.7030105@logix-tt.com обсуждение исходный текст |
Ответ на | Re: [PERFORM] Big IN() clauses etc : feature proposal (PFC <lists@peufeu.com>) |
Ответы |
Re: [PERFORM] Big IN() clauses etc : feature proposal
|
Список | pgsql-hackers |
Hi, PFC, PFC wrote: > The problem is that you need a set-returning function to retrieve > the values. SRFs don't have rowcount estimates, so the plans suck. What about adding some way of rowcount estimation to SRFs, in the way of: CREATE FUNCTION foo (para, meters) RETURNS SETOF bar AS $$ ... function code ... $$ LANGUAGE plpgsql ROWCOUNT_ESTIMATOR $$ ... estimation code ... $$ ; Internally, this could create two functions, foo (para, meters) and estimate_foo(para, meters) that are the same language and coupled together (just like a SERIAL column and its sequence). The estimator functions have an implicit return parameter of int8. Parameters may be NULL when they are not known at query planning time. What do you think about this idea? The same scheme could be used to add a CPUCOST_ESTIMATOR to expensive functions. HTH, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org
В списке pgsql-hackers по дате отправления: