Re: Crash in partition-wise join involving dummy partitioned relation
От | Ashutosh Bapat |
---|---|
Тема | Re: Crash in partition-wise join involving dummy partitioned relation |
Дата | |
Msg-id | CAFjFpRe9G0D51q8K8Pi=k6z8gAphqMj=Oafa3rfhLFAt-mAFGg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Crash in partition-wise join involving dummy partitioned relation (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Crash in partition-wise join involving dummy partitioned relation
|
Список | pgsql-hackers |
On Tue, Feb 6, 2018 at 4:04 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Feb 5, 2018 at 4:46 AM, Ashutosh Bapat > <ashutosh.bapat@enterprisedb.com> wrote: >> Here's patch taking that approach. > > I rewrote the comment in relation.h like this, which I think is more clear: > > /* > * Is given relation partitioned? > * > - * A join between two partitioned relations with same partitioning scheme > - * without any matching partitions will not have any partition in it but will > - * have partition scheme set. So a relation is deemed to be partitioned if it > - * has a partitioning scheme, bounds and positive number of partitions. > + * It's not enough to test whether rel->part_scheme is set, because it might > + * be that the basic partitioning properties of the input relations matched > + * but the partition bounds did not. > + * > + * We treat dummy relations as unpartitioned. We could alternatively > + * treat them as partitioned, but it's not clear whether that's a useful thing > + * to do. > */ The comment says why it checks both bounds and part_scheme, but it doesn't explain why we check nparts, part_rels etc. My patch had that explanation. Or may be with these changes those checks are not needed. Should we remove those? Thanks for the commit. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
В списке pgsql-hackers по дате отправления: