Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET
От | David Rowley |
---|---|
Тема | Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET |
Дата | |
Msg-id | CAApHDvq0cD18xUFFnJ2tGGFFAMU-h=gXc=g2E4sqsYX7J3__EQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Query ID Calculation Fix for DISTINCT / ORDER BY and LIMIT / OFFSET
|
Список | pgsql-hackers |
On Tue, 18 Mar 2025 at 21:00, Michael Paquier <michael@paquier.xyz> wrote: > If we make the whole cheaper with only extra entropy added for NULLs > in nodes and strings, I'd rather have an insurance policy for the > custom functions. Something like that: > - Forbid a size of 0 in AppendJumble(). > - When dealing with a non-NULL case in _jumbleNode(), save the initial > jumble_len and the jumble contents when starting, then complain if the > jumble_len matches with the initial length at the end and if the > contents are the same in an assert. A check on the length may be > enough, but we'd depend on JUMBLE_SIZE and nodes can get pretty big. > > What do you think? If it's for Assert enabled builds only, then to save from having to look at the buffer, you could have an extra field similar to jumble_len, but does not get reset when the jumble buffer fills. Just assert that the total_jumbled_bytes has grown after jumbling a node, maybe? David
В списке pgsql-hackers по дате отправления: