Re: index scan over composite type

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: index scan over composite type
Date: 2018-05-15 20:57:01
Message-ID: 21623.1526417821@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Teodor Sigaev <teodor(at)sigaev(dot)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

Attachment Content-Type Size
fix-merge-join-with-record_eq.patch text/x-diff 593 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-05-15 21:02:28 Re: explain (verbose off, normalized) vs query planid
Previous Message Robert Haas 2018-05-15 20:16:55 Re: explain (verbose off, normalized) vs query planid