From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [POC] Faster processing at Gather node |
Date: | 2017-11-09 18:35:09 |
Message-ID: | CA+TgmoYg+J+uKudgP3ZM0w5ycwLUJQ-kh3eouu4qCQXwS5-q_g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 9, 2017 at 12:08 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> This change looks suspicious to me. I think here we can't use the
> tupDesc constructed from targetlist. One problem, I could see is that
> the check for hasOid setting in tlist_matches_tupdesc won't give the
> correct answer. In case of the scan, we use the tuple descriptor
> stored in relation descriptor which will allow us to take the right
> decision in tlist_matches_tupdesc. If you try the statement CREATE
> TABLE as_select1 AS SELECT * FROM pg_class WHERE relkind = 'r'; in
> force_parallel_mode=regress, then you can reproduce the problem I am
> trying to highlight.
I tried this, but nothing seemed to be obviously broken. Then I
realized that the CREATE TABLE command wasn't using parallelism, so I
retried with parallel_setup_cost = 0, parallel_tuple_cost = 0, and
min_parallel_table_scan_size = 0. That got it to use parallel query,
but I still don't see anything broken. Can you clarify further?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-11-09 18:39:34 | Re: Simplify ACL handling for large objects and removal of superuser() checks |
Previous Message | Pavel Stehule | 2017-11-09 18:33:11 | Re: proposal: psql command \graw |