Hi, Tom, Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: >> BTW, I think it would make sense to implement a limited subset of the >> xfunc ideas: add options to CREATE FUNCTION to allow cost information to >> be specified, and then take advantage of this information instead of >> using the existing constant kludges. This would be a tangible >> improvement, and would have minimal impact on the planner. > > The trick is to figure out what a useful parameterized cost model would > look like. IIRC, the main reason the xfunc code rotted on the vine was > that its cost parameters didn't seem to be either easy to select or > powerful in predicting actual cost. We'd have to do better this time.
I don't know what the xfunc people did, but at least for some varlen data types (Arrays, PostGIS, text), some function costs (concatenation, GeomUnion etc.) can be estimated via the average field size of the tables. Has that idea been considered? HTH, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org
signature.asc
Description: OpenPGP digital signature
