Re: [HACKERS] path toward faster partition pruning

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: [HACKERS] path toward faster partition pruning
Дата
Msg-id CAFjFpRextm=MrEgOskTJS9DiE1MK31dC+Jw_w82HfYxu0-eHGg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] path toward faster partition pruning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On Thu, Mar 1, 2018 at 6:57 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> On 2018/02/28 19:14, Ashutosh Bapat wrote:
>> On Wed, Feb 28, 2018 at 6:42 AM, Amit Langote wrote:
>>> BTW, should there be a relevant test in partition_join.sql?  If yes,
>>> attached a patch (partitionwise-join-collation-test-1.patch) to add one.
>>
>> A partition-wise join path will be created but discarded because of
>> higher cost. This test won't see it in that case. So, please add some
>> data like other tests and add command to analyze the partitioned
>> tables. That kind of protects from something like that.
>
> Thanks for the review.
>
> Hmm, the added test is such that the partition collations won't match, so
> partition-wise join won't be considered at all due to differing
> PartitionSchemes, unless I'm missing something.
>

The point is we wouldn't know whether PWJ was not selected because of
PartitionScheme mismatch OR the PWJ paths were expensive compared to
non-PWJ as happens with empty tables. In both the cases we will see a
non-PWJ "plan" although in one case PWJ was not possible and in the
other it was possible. I think what we want to test is that PWJ Is not
possible with collation mismatch.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] path toward faster partition pruning
Следующее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: RE: [bug fix] Produce a crash dump before main() on Windows