Re: Use unique index for longer pathkeys. - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Use unique index for longer pathkeys.
Date
Msg-id 20140710.194000.254874346.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Use unique index for longer pathkeys.  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
List pgsql-hackers
Thank you for taking a look on this patch.

> I took a quick look at this patch, more or less because nobody else did.
> 
> > Duing last CF, I proposed to match long pathkeys against index columns
> > during creating index paths. This worked fine but also it is difficult
> > to make sure that all side-effects are eliminated. Finally Tom Lane
> > suggested to truncate pathkeys while generation of the pathkeys
> > itself. So this patch comes.
> 
> I found your older patch quite straightforward to understand, but the
> new one much more difficult to follow (but that's not saying much, I
> am not very familiar with the planner code in general).

I think it's quite natural to think so.

> Do you have any references to the discussion about the side-effects that
> needed to be eliminated with the earlier patch?

The biggest side-effects (or simplly defect) found so far is
discussed here,

http://www.postgresql.org/message-id/01bd01cf0b4e$9b960ad0$d2c22070$@etsuro@lab.ntt.co.jp

This was caused by omitting the membership of the Var under
inspection while cheking if the pathkeys is extensible.

http://www.postgresql.org/message-id/20140107.145900.196068363.horiguchi.kyotaro@lab.ntt.co.jp

After all, Tom said that the right way to do this is not such
whacking-a-mole thing but loosen pathkeys previously so that the
planner naturally do what the previous patch did without any
special treat.

http://www.postgresql.org/message-id/5212.1397599817@sss.pgh.pa.us

So the new patch comes.


regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: WAL replay bugs
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: pg_resetxlog to clear backup start/end locations.