Alexey Bashtanov writes:
> On 31/03/2020 18:53, Tom Lane wrote:
>> Renamed "matchsel" to "matchingsel" etc, added DEFAULT_MATCHING_SEL,
>> rebased over commit 911e70207. Since that commit already created
>> new versions of the relevant contrib modules, I think we can just
>> redefine what those v
On 31/03/2020 18:53, Tom Lane wrote:
Renamed "matchsel" to "matchingsel" etc, added DEFAULT_MATCHING_SEL,
rebased over commit 911e70207. Since that commit already created
new versions of the relevant contrib modules, I think we can just
redefine what those versions contain, rather than making ye
Renamed "matchsel" to "matchingsel" etc, added DEFAULT_MATCHING_SEL,
rebased over commit 911e70207. Since that commit already created
new versions of the relevant contrib modules, I think we can just
redefine what those versions contain, rather than making yet-newer
versions. (Of course, that ass
Alexey Bashtanov writes:
>> I was wondering about DEFAULT_MATCHING_SEL. The difference in purpose
>> from DEFAULT_MATCH_SEL wouldn't be too obvious, but then it probably
>> wouldn't be anyway.
> Fine with me, especially if both new functions are renamed accordingly.
Yup, that would make sense,
I was wondering about DEFAULT_MATCHING_SEL. The difference in purpose
from DEFAULT_MATCH_SEL wouldn't be too obvious, but then it probably
wouldn't be anyway.
Fine with me, especially if both new functions are renamed accordingly.
Best, Alex
Alexey Bashtanov writes:
>> So that leaves us with needing
>> to find a better name for this new one. Any ideas?
> I'm thinking of something wide like
> opersel, operjoinsel, DEFAULT_OPER_SEL
> or maybe even
> genericsel, genericjoinsel, DEFAULT_GENERIC_SEL
Seems a little *too* generic :-(
I w
So that leaves us with needing
to find a better name for this new one. Any ideas?
I'm thinking of something wide like
opersel, operjoinsel, DEFAULT_OPER_SEL
or maybe even
genericsel, genericjoinsel, DEFAULT_GENERIC_SEL
Best, Alex
Alexey Bashtanov writes:
> The only little thing I can think of is hardcoding it as 2 * DEFAULT_EQ_SEL.
> While I don't have any arguments against the value itself I think it
> should be configurable independently.
> Sadly DEFAULT_MATCH_SEL name is already taken for text patterns.
> Not sure if i
Quickly tested like this:
create table t(a jsonb);
insert into t select jsonb_object( array[(random() * 10)::int::text],
'{" "}') from generate_series(1, 10);
insert into t select jsonb_object( array[(random() * 10)::int::text],
array[(random() * 1000)::int::text]) from generate_series(1, 1
Hi Tom,
The patches look entirely reasonable to me.
The second one needs to be rebased.
I like the idea of stubbing matchjoinsel for now,
as well as being careful with operators that may correlate with sort
orderings.
The only little thing I can think of is hardcoding it as 2 * DEFAULT_EQ_SEL
I wrote:
> This patch is not complete, because I didn't look at changing
> the contrib modules, and grep says at least some of them are using
> contsel for non-geometric data types. But I thought I'd put it up
> for discussion at this stage.
Hearing nothing, I went ahead and hacked on the contrib
11 matches
Mail list logo
