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
-
Doc: add detail about EXPLAIN's "Disabled" property
- 84b8fccbe5c2 18.0 landed
-
Adjust EXPLAIN's output for disabled nodes
- 161320b4b960 18.0 landed
-
Fix order of parameters in a cost_sort call
- 87b6c3c0b703 18.0 landed
-
Show number of disabled nodes in EXPLAIN ANALYZE output.
- c01743aa4866 18.0 landed
-
Treat number of disabled nodes in a path as a separate cost metric.
- e22253467942 18.0 landed
-
Remove grotty use of disable_cost for TID scan plans.
- e4326fbc60c4 18.0 landed