From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallel Plans and Cost of non-filter functions |
Date: | 2017-11-07 03:00:16 |
Message-ID: | CAA4eK1JmGtnF7Q4O-V3Ya9-nPwXb=Opmcp0V74BXP9EW3nHBNA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 6, 2017 at 7:40 PM, Paul Ramsey <pramsey(at)cleverelephant(dot)ca> wrote:
> From my perspective, this is much much better. For sufficiently large
> tables, I get parallel behaviour without jimmying with the defaults on
> parallel_setup_cost and parallel_tuple_cost. *And*, the parallel behaviour
> *is* sensitive to the costs of functions in target lists, so reasonably
> chosen costs will flip us into a parallel mode for expensive functions
> against smaller tables too.
>
Thanks for the confirmation.
> Hopefully some variant of this finds it's way into core! Is there any way I
> can productively help?
You have already helped a lot by providing the use case, but feel free
to ping on that thread if you find it is not moving.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-11-07 03:15:49 | Re: [PATCH] A hook for session start |
Previous Message | Amit Kapila | 2017-11-07 02:57:06 | Re: why not parallel seq scan for slow functions |