Re: Functionscan estimates
От | Tom Lane |
---|---|
Тема | Re: Functionscan estimates |
Дата | |
Msg-id | 22291.1113061523@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Functionscan estimates ("Jim C. Nasby" <decibel@decibel.org>) |
Ответы |
Re: Functionscan estimates
|
Список | pgsql-performance |
"Jim C. Nasby" <decibel@decibel.org> writes: > On Sat, Apr 09, 2005 at 12:00:56AM -0400, Tom Lane wrote: >> But with all due respect to Joe, I think the reason that stuff got >> trimmed is that it didn't work very well. In most cases it's >> *hard* to write an estimator for a SRF. Let's see you produce >> one for dblink() for instance ... > Actually, if the remote database supported a way to get a rows estimate > from the query passed to db_link, it would be trivial, since you'd just > pass that back. This assumes that (1) you have the complete query argument at the time of estimation, and (2) it's OK to contact the remote database and do an EXPLAIN at that time. Both of these seem pretty shaky assumptions. The larger point is that writing an estimator for an SRF is frequently a task about as difficult as writing the SRF itself, and sometimes much *more* difficult due to lack of information. I don't foresee a whole lot of use of an estimator hook designed as proposed here. In particular, if the API is such that we can only use the estimator when all the function arguments are plan-time constants, it's not going to be very helpful. regards, tom lane
В списке pgsql-performance по дате отправления: