Re: index scan over composite type - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: index scan over composite type
Date
Msg-id 9d2be0b0-9cfe-67c3-bafb-fbdbe44cfce6@sigaev.ru
Whole thread Raw
In response to Re: index scan over composite type  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: index scan over composite type  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Thank you. Seems, it works, at least I can't find a counter-example for that.

Tom Lane wrote:
> Teodor Sigaev <teodor@sigaev.ru> writes:
>> I'm not understand why postgres prefers to sort table instead of using
>> index only scan when query is a simple inner join on composite type.
>> Query with equality clause with constant works fine with index scan but
>> join not. Could somebody point me why? Thank you.
> 
> Hmm ... the reason why not seems to be that canonicalize_ec_expression()
> improperly adds a RelabelType node, causing the composite-type Vars to not
> be recognized as matching the eclass they should match.  The attached
> patch fixes it and doesn't seem to break anything in the regression tests.
> 
> This raises the question of why we don't treat type RECORD more like a
> true polymorphic type, but that's a can of worms I don't particularly want
> to open right now.  For the moment, this is the only IsPolymorphicType
> call in the planner AFAICS, so there's some reason to hope that we don't
> have more bugs of the same ilk.
> 
>             regards, tom lane
> 

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGFIX] amcanbackward is not checked before building backward index paths
Next
From: Alvaro Herrera
Date:
Subject: Re: Postgres 11 release notes