Re: [HACKERS] [POC] Faster processing at Gather node
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] [POC] Faster processing at Gather node |
Дата | |
Msg-id | CAA4eK1JQ7kC8wjC3C40ZPH9X7csWLnHExTe5chDc+-fPhNR9OQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [POC] Faster processing at Gather node (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] [POC] Faster processing at Gather node
|
Список | pgsql-hackers |
On Fri, Nov 10, 2017 at 8:36 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Nov 9, 2017 at 9:31 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> Have you set force_parallel_mode=regress; before running the >> statement? > > Yes, I tried that first. > >> If so, then why you need to tune other parallel query >> related parameters? > > Because I couldn't get it to break the other way, I then tried this. > > Instead of asking me what I did, can you tell me what I need to do? > Maybe a self-contained reproducible test case including exactly what > goes wrong on your end? > I think we are missing something very basic because you should see the failure by executing that statement in force_parallel_mode=regress even in a freshly created database. I guess the missing point is that I am using assertions enabled build and probably you are not (If this is the reason, then it should have striked me first time). Anyway, I am writing steps to reproduce the issue. 1. initdb 2. start server 3. connect using psql 4. set force_parallel_mode=regress; 5. Create Table as_select1 AS SELECT * FROM pg_class WHERE relkind = 'r'; -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: