Re: Partition-wise aggregation/grouping

From: Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>
To: legrand legrand <legrand_legrand(at)hotmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Partition-wise aggregation/grouping
Date: 2017-12-08 04:21:17
Message-ID: CAM2+6=XLbADYS8msY9gxwQPe6ZYh5K-sWdWBtGUvqW2kQ8oW+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 8, 2017 at 3:08 AM, legrand legrand <legrand_legrand(at)hotmail(dot)com
> wrote:

> Hello,
>
> I'm testing Partition wise and found a strange result in V8 patch
> see init_star_schema_agg.sql
> <http://www.postgresql-archive.org/file/t348768/init_star_schema_agg.sql>
>
> Explain gives
> -> Seq Scan on facts_p2 (...) (actual time=0.012..0.012 rows=1 loops=1)
> for partitions that are joined with empty partitions
>
> I was expecting a message saying that partition facts_p2 was not accessed
>
> Am I wrong ?
>

Is this related to partition-wise aggregation as you saying you found this
behaviour on v8 patch?

I have tried your testcase on master and see similar plan.

I had a look over the plan and I did not see any empty relation at the
planning time.

> Regards
> PAscal
>
>
>
> --
> Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-
> f1928748.html
>
>

--
Jeevan Chalke
Technical Architect, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: +91 20 66449694

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are
not the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Tokarev 2017-12-08 04:21:45 Table with large number of int columns, very slow COPY FROM
Previous Message Huong Dangminh 2017-12-08 04:18:17 RE: User defined data types in Logical Replication