Re: [DOCS] Confusing Trigger Docs.

fashion -- something gets filled in. But I can imagine cases where it is not idempotent, and apply a before update trigger modifies the row in a way that is surprising. Just because ON CONFLICT DO UPDATE was used rather than UPDATE. That's what the documentation warns about. -- Peter

Re: [DOCS] "data" not "datums"

ums" like this. I think of it as being like the use of "people" versus the use of "persons". -- Peter Geoghegan -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] pg_stat_statements max size clarification

because pg_stat_statements is arguably too discriminating about what constitutes a distinct query/entry, but that's another problem. -- Peter Geoghegan -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] Pg_upgrade and collation

On Sat, Jul 9, 2016 at 7:02 AM, Peter Eisentraut wrote: > On 6/28/16 5:58 PM, Peter Geoghegan wrote: >> >> I have long advocated adopting ICU as our defacto standard "collation >> provider", primarily so that we can directly control collations and >> collatio

Re: [DOCS] Pg_upgrade and collation

m locking that down. * Upgrade major OS versions without difficulty. * User-defined collations, where you can mix and match certain facets of how text is sorted as you please. Basically, ICU offers rich functionality that we can bubble up to our users without too much effort, as other databa

Re: [DOCS] Pg_upgrade and collation

a project has every incentive to see things the same way as we do. The library explicitly decouples collation rule versions from algorithm versions. All of this is carefully considered, for the benefit of the numerous major database systems that use ICU. -- Peter Geoghegan -- Sen

Re: [DOCS] Pg_upgrade and collation

ort. PostgreSQL is the only major database system that I'm aware of that relies on operating system collations exclusively. I've avoided committing to work on it because I'm concerned that it would not be well received. [1] https://www.gnu.org/software/autoconf/manual/autoconf-2

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

new > index pages, but I don't think that's an interesting case.) Sure. I'm talking about a narrow issue around how things are represented in pgstatindex() only. -- Peter Geoghegan -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscr

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

uld happen. I meant where pages could accumulate without being recycled. -- Peter Geoghegan -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

t-link/left-link chains, and there are usage patterns where half-dead pages might accumulate. -- Peter Geoghegan -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

ngs like this because I care about making sure these tools are useful for teaching novice hackers about Postgres internals. I've made my point and will leave it at that, though. -- Peter Geoghegan -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

r example by updating the descriptions of the fields avg_leaf_density and leaf_fragmentation in the docs. Just a thought. -- Peter Geoghegan -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

I vote back patch. Subtle differences between the branches should be avoided. -- Peter Geoghegan

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

t; possible to see zero or multiple roots because the root's location > changes. That's already mentioned in the documentation, if somewhat > obliquely. Ah, yes. Another consequence of going in physical order. -- Peter Geoghegan -- Sent via pgsql-docs mailing list (pgsql-docs

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

─┼┼┼─── 206 │81 │ 3 │160 │42 (1 row) BTW, I am actively working on the amcheck B-Tree checker tool, and hope to post it soon. -- Peter Geoghegan -- Sent via pgsql-docs mailing list (p

Re: [HACKERS] [DOCS] The number of bytes is stored in index_size of pgstatindex() ?

attuple and pageinspect going into this kind of detail in their documentation generally. -- Peter Geoghegan -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] [HACKERS] Call for GIST/GIN/SP-GIST opclass documentation

s probably incongruous to explain the issues that way in this section of the docs. It probably suffices that that is covered in the "JSON Types" section. -- Peter Geoghegan -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] [HACKERS] Call for GIST/GIN/SP-GIST opclass documentation

e. It was a very close call in my mind, and if you favor changing the default now, in light of the few complaints we've heard, I think that's a reasonable decision. That said, as I noted in the main -bugs thread, the case presented is fairly atypical. -- Peter Geoghegan -- Sent vi