On 2020-11-17 20:33, Tom Lane wrote:
Peter Eisentraut writes:
I wrote a new patch to add a lot more tests around hash-based plans.
This is intended to apply separately from the other patch, and the other
patch would then "flip" some of the test cases.
OK, that addresses my concerns.
Peter Eisentraut writes:
> I wrote a new patch to add a lot more tests around hash-based plans.
> This is intended to apply separately from the other patch, and the other
> patch would then "flip" some of the test cases.
OK, that addresses my concerns.
regards, tom
I wrote a new patch to add a lot more tests around hash-based plans.
This is intended to apply separately from the other patch, and the other
patch would then "flip" some of the test cases.
On 2020-11-13 20:51, Tom Lane wrote:
* The new test in with.sql claims to be testing row hashing, but
Peter Eisentraut 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
Remote DBA, Training & Services
From eda6f7182cfe8ac7317d6874317ace24c7c7d5f6 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Fri, 23 Oct 2020 09:33:41 +0200
Subject: [PATCH v2] Hash support for row types
Add hash functions for the record type as well as a hash operator
family and
Robert Haas writes:
> Do we need to worry about what happens if somebody modifies the
> opclass/opfamily definitions?
There's a lot of places that you can break by doing that. I'm not
too concerned about it.
regards, tom lane
On Tue, Oct 20, 2020 at 11:10 AM Peter Eisentraut
wrote:
> On 2020-10-20 01:32, Andres Freund wrote:
> > How does this deal with row types with a field that doesn't have a hash
> > function? Erroring out at runtime could cause queries that used to
> > succeed, e.g. because all fields have btree
On 2020-10-20 01:32, Andres Freund wrote:
How does this deal with row types with a field that doesn't have a hash
function? Erroring out at runtime could cause queries that used to
succeed, e.g. because all fields have btree ops, to fail, if we just have
a generic unconditionally present hash
Hi,
On 2020-10-19 10:01:14 +0200, Peter Eisentraut wrote:
> In [0] it was discussed that hash support for row types/record would be
> handy. So I implemented that.
> The implementation hashes each field and combines the hash values. Most of
> the code structure can be borrowed fro
In [0] it was discussed that hash support for row types/record would be
handy. So I implemented that.
The implementation hashes each field and combines the hash values. Most
of the code structure can be borrowed from the record comparison
functions/btree support. To combine the hash values
10 matches
Mail list logo
