than vardata.rel->rows.
Accurate estimation need good math model that considering dependency of
join var and vars in restriction.
But at least, indistinct should not be greater than the number of rows.
See the attached patch to adjust nd in eqjoinsel.
Best,
Zhenghua Lyu
0001-Adjust-n
Thanks for your explanation.
From: David G. Johnston
Sent: Wednesday, December 8, 2021 11:39 PM
To: Zhenghua Lyu
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Question on not-in and array-eq
On Wed, Dec 8, 2021 at 8:15 AM Zhenghua Lyu
mailto:z
Hi,
I run the following SQL in Postgres (14_STABLE), and got the results:
zlyu=# create table t1(a int, b int);
CREATE TABLE
zlyu=# create table t2(a int, b int);
CREATE TABLE
zlyu=# insert into t1 values (null, 1);
INSERT 0 1
zlyu=# insert into t2 values (1, 1);
INSERT 0 1
zlyu=# select * from
onday, October 26, 2020 10:37 PM
To: Zhenghua Lyu
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Should the function get_variable_numdistinct consider the case
when stanullfrac is 1.0?
Zhenghua Lyu writes:
>It seems the function `get_variable_numdistinct` ignore the case when
> stanull
Hi hackers,
It seems the function `get_variable_numdistinct` ignore the case when
stanullfrac is 1.0:
# create table t(a int, b int);
CREATE TABLE
# insert into t select i from generate_series(1, 1)i;
INSERT 0 1
gpadmin=# analyze t;
ANALYZE
# explain analyze select b, count(1) from t
Hi Jesse,
you are right.
For the nestloop case, they are identical.
I do not come up with hash join or mergejoin case in pg now.
From: Jesse Zhang
Sent: Thursday, July 16, 2020 2:16 PM
To: Zhenghua Lyu
Cc: Amit Kapila ; PostgreSQL Hackers
Subject: Re
___
From: Amit Kapila
Sent: Thursday, July 16, 2020 12:07 PM
To: Zhenghua Lyu
Cc: PostgreSQL Hackers
Subject: Re: Volatile Functions in Parallel Plans
On Wed, Jul 15, 2020 at 6:14 PM Zhenghua Lyu wrote:
>
>
> The first plan:
>
> Finalize Aggregate
>
Hi,
I test some SQL in the latest Postgres master branch code (we find these
issues when
developing Greenplum database in the PR
https://github.com/greenplum-db/gpdb/pull/10418,
and my colleague come up with the following cases in Postgres):
create table t3 (c1 text, c2 text);
CREATE TABLE
i
above case and ask here.
To be honest, I do not care the push down so much. It is not normal usage
to writing volatile functions in where clause.
I just find it lose the property.
Best,
Zhenghua Lyu
From: Tom Lane
Sent: Friday, July 10, 2020 10:10
different property:
* the first one, if we push down, can only produce 2 results: 0 rows, or
10 rows. No third possibility
* the second one, will output 0 ~ 10 rows with equal probability.
I am wondering if we should consider volatile functions in restrictinfo
when try to distribute_restrictinfo_to_rels?
Best,
Zhenghua Lyu
ny thoughts or ideas on the problem? Thanks!
Best Regards,
Zhenghua Lyu
Thanks so much.
I understand now.
Best Regards,
Zhenghua Lyu
On Mon, Jun 10, 2019 at 3:22 PM Kuntal Ghosh
wrote:
> On Mon, Jun 10, 2019 at 12:42 PM Etsuro Fujita
> wrote:
>
>> Hi,
>>
>> On Mon, Jun 10, 2019 at 3:50 PM Kuntal Ghosh
>> wrote:
>> >
, my questions are:
1. why after emitting `lockrows` plannode, the result can no longer be
assumed sorted?
2. Is the case above a bug or a feature?
Thanks!
Best Regards,
Zhenghua Lyu
ld skip the two "new", "old"
RangeTblEntry.
How to fix this:
1. forbid the syntax: rule's command cannot be a select-for-update
2. skip new and old: I have a patch to show this idea, please see the
attachment.
Any thoughts? Thanks!
Best Regards,
Zhenghua Lyu
0
14 matches
Mail list logo