| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: why not parallel seq scan for slow functions |
| Date: | 2017-11-08 13:18:41 |
| Message-ID: | CA+TgmoYCsXb+ZyzOKnLpJyfwNk4EXJ8hBoNme8uhdhZGZWtUfg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Nov 8, 2017 at 7:26 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> We do want to generate it later when there isn't inheritance involved,
> but only if there is a single rel involved (simple_rel_array_size
> <=2). The rule is something like this, we will generate the gather
> paths at this stage only if there are more than two rels involved and
> there isn't inheritance involved.
Why is that the correct rule?
Sorry if I'm being dense here. I would have thought we'd want to skip
it for the topmost scan/join rel regardless of the presence or absence
of inheritance.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2017-11-08 14:21:11 | Re: SQL procedures |
| Previous Message | Amit Kapila | 2017-11-08 12:26:16 | Re: why not parallel seq scan for slow functions |