Re: Proposed refactoring of planner header files
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-02-13T21:38:35Z
Lists: pgsql-hackers
Attachments
- split-out-pattern-selfuncs-1.patch (text/x-diff) patch
Pursuant to this discussion about breaking up selfuncs.c, here's a proposed patch to shove all the planner logic associated with LIKE and regex operators into the recently-created like_support.c file. This takes a bit under 1400 lines out of selfuncs.c. I was fairly pleased at how neatly this broke up. I had to export ineq_histogram_selectivity() and var_eq_const() from selfuncs.c because some of the moved functions called those; and I also exported var_eq_non_const() because it seemed to make sense for that to be visible if var_eq_const() is. But otherwise there aren't connections between the two files. I made pattern_fixed_prefix() and make_greater_string() static in like_support.c, since all of their callers are there now. It's possible that somebody is using those from an extension, in which case I wouldn't have a big problem with re-exporting them, but let's wait and see if there's actually any complaints. This isn't quite purely a code-motion patch: I failed to resist the temptation to refactor patternsel() slightly so that the LIKE/regex support functions can call it for SupportRequestSelectivity. That means that invoking LIKE/regex through function syntax is exactly on par with invoking it through operator syntax, so far as the planner is concerned: not only can we extract lossy index conditions from something like "WHERE like(textcolumn, 'foo%bar')", but we get the right selectivity estimate too. (HEAD can only do the former.) I should emphasize that I'm not that excited about whether calling like() as a function is well-supported, and I'd certainly not propose that we make any large-scale effort to make this work for other built-in operators. But I think that extensions like PostGIS may very well have reason to want their functions and operators to have parity, so there should be an example in the core code of how to do it. Barring objections I'll push this shortly. I'm not done looking at selfuncs.c, but this is a separable piece. regards, tom lane
Commits
-
Refactor index cost estimation functions in view of IndexClause changes.
- e89f14e2bb9f 12.0 landed
-
Simplify the planner's new representation of indexable clauses a little.
- 8fd3fdd85a3e 12.0 landed
-
Move pattern selectivity code from selfuncs.c to like_support.c.
- 49fa99e54ec0 12.0 landed
-
Refactor planner's header files.
- f09346a9c621 12.0 landed
-
Make some small planner API cleanups.
- a1b8c41e990e 12.0 landed