Re: Proposal: roll pg_stat_statements into core

David Fetter <david(at)fetter(dot)org> writes:
> - It's broadly useful.

Maybe. Whether it can be argued that it's so broadly useful as
to justify being on-by-default is not clear.

> - Right now, the barrier for turning it on is quite high. In addition
> to being non-core, which is already a pretty high barrier at a lot
> of organizations, it requires a shared_preload_libraries setting,
> which is pretty close to untenable in a lot of use cases.

That argument seems pretty weak. It's part of contrib and therefore
maintained by the same people as the "core" code. Also, I don't buy
for a minute that people who would need it don't also need a bunch of
other changes in default GUC settings (shared_buffers etc).

> - The overhead for most use cases is low compared to the benefit.

Please do not expect that we're going to accept such assertions
unsupported by evidence. (As a very quick-n-dirty test, I tried
"pgbench -S" and got somewhere around 4% TPS degradation with
pg_stat_statements loaded. That doesn't seem negligible.)

I think also that we would need to consider the migration penalty
for people who already have the contrib version installed. To
judge by previous cases (I'm thinking tsearch2) that could be
pretty painful. Admittedly, tsearch2 might not be a good comparison,
but points as simple as "the views/functions won't be in the same
schema as before" are enough to cause trouble.

regards, tom lane