From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Hash support for row types |
Date: | 2020-11-13 19:51:48 |
Message-ID: | 395784.1605297108@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Lakhin | 2020-11-13 20:00:00 | Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction |
Previous Message | Jacob Champion | 2020-11-13 19:07:38 | Re: Zedstore - compressed in-core columnar storage |