On Sat, Apr 20, 2024 at 01:56:48PM +1200, David Rowley wrote:
> Thanks for the review. I've now pushed this, backpatching to 12.
You've split that into two separate paragraphs with 2d3389c28c5c.
Thanks for the commit.
--
Michael
signature.asc
Description: PGP signature
On Tue, 16 Apr 2024 at 15:16, Michael Paquier wrote:
>
> On Tue, Apr 16, 2024 at 02:04:22PM +1200, David Rowley wrote:
> > It makes sense to talk about the hashing variations closer to the
> > object identifier part.
>
> Mostly what I had in mind. A separate for the new part you are
> adding at
On Tue, Apr 16, 2024 at 02:04:22PM +1200, David Rowley wrote:
> It makes sense to talk about the hashing variations closer to the
> object identifier part.
Mostly what I had in mind. A separate for the new part you are
adding at the end of the first part feels a bit more natural split
here. Fee
On Tue, 16 Apr 2024 at 12:10, Michael Paquier wrote:
> Not sure that this is an improvement in clarity. There are a few
> bullet points that treat about the instability of the query ID, and
> your patch is now mixing the query ID being different for two
> mostly-identical queries on the same host
On Mon, Apr 15, 2024 at 02:54:52PM +1200, David Rowley wrote:
> pg_stat_statements will consider two
> apparently-identical
> queries to be distinct, if they reference a table that was dropped
> and recreated between the executions of the two queries.
> + Two servers participating in
On Mon, 15 Apr 2024 at 14:09, Michael Paquier wrote:
>
> On Mon, Apr 15, 2024 at 01:31:47PM +1200, David Rowley wrote:
> > I'm unsure if "Rule of thumb" is the correct way to convey that. We
> > can't really write "We endeavour to", as who is "We". Maybe something
> > like "Generally, it can be a
On Sun, Apr 14, 2024 at 7:03 PM David Rowley wrote:
> On Mon, 15 Apr 2024 at 13:37, David G. Johnston
> wrote:
> > Seems we can improve things by simply removing the "rule of thumb"
> sentence altogether. The prior paragraph states the things the queryid
> depends upon at the level of detail th
On Mon, Apr 15, 2024 at 01:31:47PM +1200, David Rowley wrote:
> I think a soft guarantee in the docs for it being stable in minor
> versions would be ok then.
>
> I'm unsure if "Rule of thumb" is the correct way to convey that. We
> can't really write "We endeavour to", as who is "We". Maybe some
On Mon, 15 Apr 2024 at 13:37, David G. Johnston
wrote:
> Seems we can improve things by simply removing the "rule of thumb" sentence
> altogether. The prior paragraph states the things the queryid depends upon
> at the level of detail the reader needs.
I don't think that addresses the followin
On Sun, Apr 14, 2024 at 6:32 PM David Rowley wrote:
> On Mon, 15 Apr 2024 at 13:19, Tom Lane wrote:
> >
> > Michael Paquier writes:
> > > On Mon, Apr 15, 2024 at 11:20:16AM +1200, David Rowley wrote:
> > >> 1. We cannot change Node enums in minor versions
> > >> 2. We're *unlikely* to add field
On Sun, Apr 14, 2024 at 4:20 PM David Rowley wrote:
>
> I've drafted a patch which I think improves things, but it probably
> needs more work and opinions.
>
>
Seems we can improve things by simply removing the "rule of thumb" sentence
altogether. The prior paragraph states the things the queryi
On Mon, 15 Apr 2024 at 13:19, Tom Lane wrote:
>
> Michael Paquier writes:
> > On Mon, Apr 15, 2024 at 11:20:16AM +1200, David Rowley wrote:
> >> 1. We cannot change Node enums in minor versions
> >> 2. We're *unlikely* to add fields to Node types in minor versions, and
> >> if we did we'd likely
On Mon, 15 Apr 2024 at 12:04, Michael Paquier wrote:
> Since 16 these new fields would be added by default unless the node
> attribute query_jumble_ignore is appended to it. I agree that this
> may not be entirely intuitive when it comes to force compatibility
> across the same major version. Co
Michael Paquier writes:
> On Mon, Apr 15, 2024 at 11:20:16AM +1200, David Rowley wrote:
>> 1. We cannot change Node enums in minor versions
>> 2. We're *unlikely* to add fields to Node types in minor versions, and
>> if we did we'd likely be leaving them out of the jumble calc, plus it
>> seems hi
On Sun, Apr 14, 2024 at 9:01 PM David Rowley wrote:
> On Mon, 15 Apr 2024 at 11:47, Peter Geoghegan wrote:
> > Technically we don't promise that WAL records won't change in minor
> > versions. In fact, the docs specifically state that the format of any
> > WAL record might change, and that users
On Mon, 15 Apr 2024 at 11:47, Peter Geoghegan wrote:
>
> On Sun, Apr 14, 2024 at 7:20 PM David Rowley wrote:
> > It's the "underlying server version" that I think needs some
> > clarification. It's unclear if the minor version must match or just
> > the major version number. The preceding paragra
On Sun, Apr 14, 2024 at 8:04 PM Michael Paquier wrote:
> Assuming that a query ID will be always stable across major versions
> is overconfident, I think. As Peter said, like for WAL, we may face
> cases where a slight breakage for a subset of queries could be
> justified, and pg_stat_statement w
On Mon, Apr 15, 2024 at 11:20:16AM +1200, David Rowley wrote:
> I was recently asked internally about the stability guarantees we
> offer for queryid. My answer consisted of:
>
> 1. We cannot change Node enums in minor versions
> 2. We're *unlikely* to add fields to Node types in minor versions,
On Sun, Apr 14, 2024 at 7:20 PM David Rowley wrote:
> It's the "underlying server version" that I think needs some
> clarification. It's unclear if the minor version must match or just
> the major version number. The preceding paragraph does mention:
>
> "Furthermore, it is not safe to assume that
I was recently asked internally about the stability guarantees we
offer for queryid. My answer consisted of:
1. We cannot change Node enums in minor versions
2. We're *unlikely* to add fields to Node types in minor versions, and
if we did we'd likely be leaving them out of the jumble calc, plus i
20 matches
Mail list logo
