Re: On disable_cost

Jonathan S. Katz <jkatz@postgresql.org>

From: "Jonathan S. Katz" <jkatz@postgresql.org>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, David Rowley <dgrowleyml@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, andrew@ankane.org
Date: 2024-08-23T21:29:10Z
Lists: pgsql-hackers
On 8/23/24 2:29 PM, Robert Haas wrote:
> On Fri, Aug 23, 2024 at 2:20 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>> I don't think extension maintainers necessarily have the same level of
>> PostgreSQL internals as you or many of the other people who frequent
>> -hackers, so I think it's fair for them to ask questions or raise issues
>> with patches they don't understand. I was able to glean from the commit
>> message that this was the commit that likely changed the behavior in
>> pgvector, but I can't immediately glean looking through the code as to
>> why. (And using your logic, should an extension maintainer understand
>> the optimizer code when PostgreSQL is providing an interface to the
>> extension maintainer to encapsulate its interactions)?
>>
>> You can always push back and say "Well, maybe try this, or try that" -
>> which would be a mentoring approach that could push it back on the
>> extension maintainer, which is valid, but I don't see why an extension
>> maintainer can't raise an issue or ask a question here.
> 
> I'm certainly not saying that extension maintainers can't raise issues
> or ask questions here. I just feel that the problem could have been
> analyzed a bit more before posting.

This assumes that the person posting the problem has the requisite 
expertise to determine what the issue is. Frankly, I was happy I was 
able to at least trace the issue down to the particular commit and 
brought what appeared to be a reliable reproducer, in absence of knowing 
if 1/ this was actually an issue with PG or pgvector, 2/ does it 
actually require a fix, or 3/ what the problem could actually be, given 
a lack of understanding of the full inner working of the optimizer.

Based on the above, I'm not sure what bar this needed to clear to begin 
a discussion on the mailing list (which further downthread, seems to be 
raising some interesting points).

Jonathan

Commits

  1. Doc: add detail about EXPLAIN's "Disabled" property

  2. Adjust EXPLAIN's output for disabled nodes

  3. Fix order of parameters in a cost_sort call

  4. Show number of disabled nodes in EXPLAIN ANALYZE output.

  5. Treat number of disabled nodes in a path as a separate cost metric.

  6. Remove grotty use of disable_cost for TID scan plans.