Joshua D. Drake wrote:
> Alvaro Herrera wrote:
>> Joshua D. Drake wrote:
>>> Heikki Linnakangas wrote:
>>>> Joshua D. Drake wrote:
>
>>> I guess my point is, if the patch looks good and does not appear to hurt
>>> anything, why not apply it? At least that way we can start to review the
>>> progress of the feature itself as it starts to see use.
>> Yeah, you mean like commit_delay. It really worked great, that
>> reviewing of a feature, you know. It only took 3 years until someone
>> realized that it didn't work as advertised.
>
> You can not compare the relevant smallness of use from three years ago
> to the explosion of use at present. It is certainly unfortunate that
> commit_delay didn't work as advertised, but then again had we not
> applied it, we would have never known in the first place and now we have
> the opportunity to fix or remove it.
I don't think we can work like that anymore. For a performance patch,
you ought to have at least a one repeatable test case where the patch
improves performance. Then you can start talking about tradeoffs with
code complexity, possible performance losses in other less common use
cases etc, but if you can't demonstrate any meaningful benefit
whatsoever in any use case, it's dead on arrival.
> You can compare other such features that many people don't touch that
> are starting to show promise over time such as cpu_tuple_cost.
That's different. Even though choosing the right plan surely has an
effect on performance, cpu_tuple_cost more like a functional feature
than a performance feature..
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
