[ 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
15 matches
Mail list logo
