Re: postgres_fdw bug in 9.6

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgres_fdw bug in 9.6
Date: 2017-01-05 03:00:07
Message-ID: c1075e4e-8297-5cf6-3f30-cb21266aa2ee@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016/12/27 22:03, Ashutosh Bapat wrote:

You wrote:
>>> 3. Talking about saving some CPU cycles - if a clauseless full join can be
>>> implemented only using merge join, probably that's the only path available
>>> in
>>> the list of paths for the given relation. Instead of building the same
>>> path
>>> anew, should we use the existing path like GetExistingLocalJoinPath() for
>>> that
>>> case?

I wrote:
>> Hm, that might be an idea, but my concern about that is: the existing path
>> wouldn't always be guaranteed to be unprameterized.

> Why? We retain all the parameterizations (including no
> parameterization) available in the pathlist, so if it's possible to
> create an unparameterized path, there will be one.

OK, but another concern is: in cases when we consider parameterized
paths, it might be inefficient to search the pathlist because the
unparameterized path might be at the rear of the lengthy pathlist. Note
that patameterized paths would produce fewer rows and have reduced
transfer and hence total cost, so they would be in the more front of the
pathlist, and the unparameterized path would be in the more rear. (Note
that the pathlist is kept sorted by total cost.)

Best regards,
Etsuro Fujita

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2017-01-05 03:10:32 Re: HASH_CHUNK_SIZE vs malloc rounding
Previous Message Etsuro Fujita 2017-01-05 02:50:25 Re: postgres_fdw bug in 9.6