[ moving this discussion to a more appropriate thread; let's keep the
original thread for discussing whether bloom actually needs fixed ]
Over in
https://www.postgresql.org/message-id/CAMkU=1yHfC+Gu84UFsz4hWn=c7tgqfmlieqcto1y-8wde96...@mail.gmail.com
Jeff Janes writes:
> On Tue, Feb 12, 2019 a
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 brok
Robert Haas writes:
> I do not have a powerful opinion on exactly what to do here, but I
> offer the following for what it's worth:
> - I do not really think much of the selfuncs.c naming. Nobody who is
> not deeply immersed in the PostgreSQL code knows what a "selfunc" is.
> Therefore, breaking
On Thu, Jan 31, 2019 at 2:46 PM Tom Lane wrote:
> I'm happy to do the work if there's consensus on what to do. After
> a few moments' thought, I'd suggest:
>
> 1. Move the indexscan cost estimation functions into a new file
> adt/index_selfuncs.c. Most of them already are declared in
> utils/ind
Robert Haas writes:
> On Wed, Jan 30, 2019 at 10:08 PM Tom Lane wrote:
>> However ... there are three pretty clearly identifiable groups of
>> functions in selfuncs.c: operator-specific estimators, support
>> functions, and AM-specific indexscan cost estimation functions.
>> There's a case to be
On Wed, Jan 30, 2019 at 10:08 PM Tom Lane wrote:
> However ... there are three pretty clearly identifiable groups of
> functions in selfuncs.c: operator-specific estimators, support
> functions, and AM-specific indexscan cost estimation functions.
> There's a case to be made for splitting them int
I wrote:
> ... I didn't work on tightening selfuncs.c's dependencies.
> While I don't have a big problem with considering selfuncs.c to be
> in bed with the planner, that's risky in that whatever dependencies
> selfuncs.c has may well apply to extensions' selectivity estimators too.
> What I'm thin
Robert Haas writes:
> On Mon, Jan 28, 2019 at 3:17 PM Tom Lane wrote:
>> I'm really unhappy that force_parallel_mode and
>> parallel_leader_participation are being treated as planner GUCs.
> The only use of parallel_leader_participation at plan time seems to be
> to twiddle the costing, and the
Andres Freund writes:
> On 2019-01-28 13:02:11 -0800, Andres Freund wrote:
>> It's not required by C99, it however is required by C11. But a lot of
>> compilers have allowed it as an extension for a long time (like before
>> C99), unless suppressed by some option.
> Hm, it's only in gcc 4.6, so t
Andres Freund writes:
> On 2019-01-28 15:50:22 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> Ugh, isn't it nicer to just use the underlying struct type instead of
>>> that?
>> No, because that'd mean that anyplace relying on optimizer.h would also
>> have to write "struct PlannerInfo" rath
Hi,
On 2019-01-28 13:02:11 -0800, Andres Freund wrote:
> It's not required by C99, it however is required by C11. But a lot of
> compilers have allowed it as an extension for a long time (like before
> C99), unless suppressed by some option. I think that's partially because
> C++ has allowed it fo
Hi,
On 2019-01-28 15:50:22 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-01-28 15:17:19 -0500, Tom Lane wrote:
> >> Since I was intentionally trying to limit what optimizer.h pulls in,
> >> and in particular not let it include relation.h, I needed an opaque
> >> typedef for PlannerIn
Andres Freund writes:
> On 2019-01-28 15:17:19 -0500, Tom Lane wrote:
>> Since I was intentionally trying to limit what optimizer.h pulls in,
>> and in particular not let it include relation.h, I needed an opaque
>> typedef for PlannerInfo. On the other hand relation.h also needs to
>> typedef th
On Mon, Jan 28, 2019 at 3:17 PM Tom Lane wrote:
> I'm really unhappy that force_parallel_mode and
> parallel_leader_participation are being treated as planner GUCs.
> They are not that, IMO, because they also affect the behavior of
> the executor, cf HandleParallelMessage, ExecGather, ExecGatherMe
Hi,
On 2019-01-28 15:17:19 -0500, Tom Lane wrote:
> In <6044.1548524...@sss.pgh.pa.us> I worried about how much planner
> stuff that patch might end up dragging into files that contain
> planner support functions, and suggested that we could refactor the
> planner's header files to reduce the incl
In <6044.1548524...@sss.pgh.pa.us> I worried about how much planner
stuff that patch might end up dragging into files that contain
planner support functions, and suggested that we could refactor the
planner's header files to reduce the inclusion footprint. Attached
are some proposed patches to imp
16 matches
Mail list logo
