On Tue, Jul 06, 2021 at 01:09:56PM +1200, David Rowley wrote:
> On Tue, 9 Mar 2021 at 05:13, Ibrar Ahmed wrote:
> > It was a minor change therefore I rebased the patch, please take a look.
>
[...]
>
> This is not really an acceptable way to determine the notnull
> attribute value. Andy Fan propo
On Tue, 9 Mar 2021 at 05:13, Ibrar Ahmed wrote:
> It was a minor change therefore I rebased the patch, please take a look.
I only had a quick look at the v3 patch.
+ rel = table_open(rte->relid, NoLock);
+ att = TupleDescAttr(rel->rd_att, var->varattno - 1);
+ if (att->attnotnull && !check_null
On Tue, 8 Sept 2020 at 13:46, Tom Lane wrote:
>
> I've been doing some handwaving about changing the representation
> of Vars, with an eye to making it clear by inspection whether a
> given Var is nullable by some lower outer join [2]. If that work
> ever comes to fruition then the need for "chec
Hi Ibrar,
On Mon, Mar 8, 2021 at 8:13 AM Ibrar Ahmed wrote:
>
> It was a minor change therefore I rebased the patch, please take a look.
>
It is perfect thank you
regards
Surafel
On Tue, Nov 24, 2020 at 12:47 PM Surafel Temesgen
wrote:
> Hi Pavel Borisov,
> It's always good to select the optimal way even if it didn't have
> performance gain
> but in case of this patch i see 4x speed up on my laptop and it will work
> on any
> table that have NULL constraint
>
> regards
>
Hi Pavel Borisov,
It's always good to select the optimal way even if it didn't have
performance gain
but in case of this patch i see 4x speed up on my laptop and it will work
on any
table that have NULL constraint
regards
Surafel
Thank you for working on this!
I got slightly into this patch. I can be wrong, but my opinion is that
planner/optimizer-related changes are not without dangers generally. So
anyway, they should be justified by performance increase, or the previous
behavior should be considered totally wrong. Pa
On Tue, Sep 8, 2020 at 12:59 PM Surafel Temesgen
wrote:
> Hi Tom
>
> On Tue, Sep 8, 2020 at 4:46 AM Tom Lane wrote:
>
>
>> The "check_null_side" code you're proposing seems really horrid.
>> For one thing, it seems quite out of place for eval_const_expressions
>> to be doing that. For another,
On Tue, 8 Sep 2020 at 07:16, Tom Lane wrote:
>
>
> I'm not sure what I think about Ashutosh's ideas about doing this
> somewhere else than eval_const_expressions. I do not buy the argument
> that it's interesting to do this separately for each child partition.
> Child partitions that have attnot
Hi Tom
On Tue, Sep 8, 2020 at 4:46 AM Tom Lane wrote:
> Surafel Temesgen writes:
> > [ null_check_on_pkey_optimization_v1.patch ]
>
> I took a very brief look at this.
>
> > I don’t add NOT NULL constraint optimization to the patch because cached
> > plan is not invalidation in case of a change
Surafel Temesgen writes:
> [ null_check_on_pkey_optimization_v1.patch ]
I took a very brief look at this.
> I don’t add NOT NULL constraint optimization to the patch because cached
> plan is not invalidation in case of a change in NOT NULL constraint
That's actually not a problem, even though s
Hi ,
Thank you for looking into this
On Fri, Aug 28, 2020 at 9:48 AM Ashutosh Bapat
wrote:
> }
> else
> has_nonconst_input = true;
> @@ -3382,7 +3395,47 @@ eval_const_expressions_mutator(Node *node,
>
> +
> +
Hi Surafel,
On Thu, Aug 27, 2020 at 6:01 PM Surafel Temesgen wrote:
>
> Hi,
>
> In good written query IS NULL and IS NOT NULL check on primary and non null
> constraints columns should not happen but if it is mentioned PostgreSQL have
> to be smart enough for not checking every return result ab
Hi,
In good written query IS NULL and IS NOT NULL check on primary and non null
constraints columns should not happen but if it is mentioned PostgreSQL
have to be smart enough for not checking every return result about null
value on primary key column. Instead it can be evaluate its truth value an
14 matches
Mail list logo
