Re: Additional Statistics Hooks
От | Tom Lane |
---|---|
Тема | Re: Additional Statistics Hooks |
Дата | |
Msg-id | 25447.1520962543@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Additional Statistics Hooks (Mat Arye <mat@timescale.com>) |
Список | pgsql-hackers |
Mat Arye <mat@timescale.com> writes: > An example, of a case a protransform type system would not be able to > optimize is mathematical operator expressions like bucketing integers by > decile --- (integer / 10) * 10. Uh, why not? An estimation function that is specific to integer divide shouldn't have much trouble figuring out that x/10 has one-tenth as many distinct values as x does. I'd certainly rather have that knowledge associated directly with int4div, and the corresponding knowledge about date_trunc associated with that function, and similar knowledge about extension-provided operators provided by the extensions, than try to maintain a hook function that embeds all such knowledge. > I also think that the point with extended statistics is a good one and > points to the need for more experimentation/experience which I think > a C hook is better suited for. Putting in a hook will allow extension > writers like us to experiment and figure out the kinds of transform on > statistics that are useful while having > a small footprint on the core. If you're experimenting you might as well just change the source code. A hook is only useful if you're trying to ship something for production, and I doubt that factorizing things this way is a credible production solution. regards, tom lane
В списке pgsql-hackers по дате отправления: