How to retain lesser paths at add_path()? - Mailing list pgsql-hackers

From Kohei KaiGai
Subject How to retain lesser paths at add_path()?
Date
Msg-id CAOP8fzYM3fhisZ1exZOZmjF8LA5Zo+XFLDFk2o6qOiuUHs62fg@mail.gmail.com
Whole thread Raw
Responses Re: How to retain lesser paths at add_path()?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hello,

When we add a new path using add_path(), it checks estimated cost and path-keys,
then it also removes dominated paths, if any.
Do we have a reasonable way to retain these "dominated" paths? Once it
is considered
lesser paths at a level, however, it may have a combined cheaper cost
with upper pathnode.

In my case, PG-Strom adds CustomPath to support JOIN/GROUP BY
workloads that utilizes
GPU and NVME storage. If GpuPreAgg and GpuJoin are executed
continuously, output buffer
of GpuJoin simultaneously performs as input buffer of GpuPreAgg on GPU
device memory.
So, it allows to avoid senseless DMA transfer between GPU and CPU/RAM.
This behavior
affects cost estimation during path construction steps - GpuPreAgg
discount DMA cost if its
input path is GpuJoin.
On the other hands, it looks to me add_path() does not consider upper
level optimization
other than sorting path-keys. As long as we can keep these "lesser"
pathnodes that has
further optimization chance, it will help making more reasonable query plan.

Do we have any reasonable way to retain these paths at add_path() even
if it is dominated
by other paths? Any idea welcome.

Best regards,

[*] GpuJoin + GpuPreAgg combined GPU kernel
https://www.slideshare.net/kaigai/20181016pgconfeussd2gpumulti/13
-- 
HeteroDB, Inc / The PG-Strom Project
KaiGai Kohei <kaigai@heterodb.com>



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Avoiding hash join batch explosions with extreme skew and weird stats
Next
From: Michael Paquier
Date:
Subject: Re: Possible race condition in pg_mkdir_p()?