Re: Proposed refactoring of planner header files

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposed refactoring of planner header files
Date: 2019-02-13 21:38:35
Message-ID: 24537.1550093915@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
split-out-pattern-selfuncs-1.patch text/x-diff 85.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-02-13 21:42:20 Re: subscriptionCheck failures on nightjar
Previous Message Andrew Gierth 2019-02-13 21:12:30 Re: Using POPCNT and other advanced bit manipulation instructions