On Tue, Jul 1, 2025 at 2:03 PM Heikki Linnakangas wrote:
> I like how this makes row comparisons less special. To be honest I don't
> quite understand what the bug was, I'd have to dig much deeper into this
> to swap enough context into my memory for that.
If you're interested, I can provide you
On 01/07/2025 19:37, Peter Geoghegan wrote:
On Fri, Jun 27, 2025 at 5:35 PM Peter Geoghegan wrote:
Attached is v4, which is largely just a polished version of v3. It has
improved comments and more worked out commit messages. Plus the second
patch (the row compare patch) now teaches _bt_first to
On Fri, Jun 27, 2025 at 5:35 PM Peter Geoghegan wrote:
> Attached is v4, which is largely just a polished version of v3. It has
> improved comments and more worked out commit messages. Plus the second
> patch (the row compare patch) now teaches _bt_first to fully rely on
> scan key requiredness ma
On Wed, Jun 25, 2025 at 5:44 PM Peter Geoghegan wrote:
> Correction: there *is* a live bug like this on Postgres 18/HEAD, which
> involves simple scalar inequalities with an incomplete opfamily.
> Attached v3 fixes the bug in its new 0001-* patch.
Attached is v4, which is largely just a polished
On Wed, Jun 18, 2025 at 8:41 PM Peter Geoghegan wrote:
> In general, when we end a primitive index scan, the code that sets
> continuescan=false (any such code, not just _bt_check_rowcompare NULL
> row member code) has to make sure that starting the next primitive
> index scan will actually allow
On Wed, Jun 18, 2025 at 8:41 PM Peter Geoghegan wrote:
> Attached patch shows how this could work. It refines the rules around
> NULL row comparison members in _bt_check_rowcompare, and in _bt_first.
> The fundamental idea here is to make _bt_check_rowcompare *consistent*
> with _bt_first. That wa
