From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
cc: pgsql-hackers <pgsql-hackers@postgresql.org>,
        Andres Freund <andres@anarazel.de>
Subject: Re: Hash support for row types
In-reply-to: <f7195e93-ab9d-01f0-1140-361aece79248@2ndquadrant.com>
References: <38eccd35-4e2d-6767-1b3c-dada1eac3124@2ndquadrant.com>
 <20201019233234.r6lyxbvdg5s77rvd@alap3.anarazel.de>
 <e88b1974-5987-9ae8-7e54-7d66f54751cb@2ndquadrant.com>
 <f7195e93-ab9d-01f0-1140-361aece79248@2ndquadrant.com>
Comments: In-reply-to Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
	message dated "Fri, 23 Oct 2020 09:49:15 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <395783.1605297108.1@sss.pgh.pa.us>
Date: Fri, 13 Nov 2020 14:51:48 -0500
Message-ID: <395784.1605297108@sss.pgh.pa.us>
Precedence: bulk

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> Here is an updated patch with the type cache integration added.

> To your point, this now checks each fields hashability before 
> considering a row type as hashable.  It can still have run-time errors 
> for untyped record datums, but that's not something we can do anything 
> about.

This looks good code-wise.  A couple small niggles on the tests:

* The new test in with.sql claims to be testing row hashing, but
it's not very apparent that any such thing actually happens.  Maybe
EXPLAIN the query, as well as execute it, to confirm that a
hash-based plan is used.

* Is it worth devising a test case in which hashing is not possible
because one of the columns isn't hashable?  I have mixed feelings
about this because the set of suitable column types may decrease
to empty over time, making it hard to maintain the test case.

I marked it RFC.

			regards, tom lane