| From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
|---|---|
| To: | "Mark Dilger" <mark(dot)dilger(at)enterprisedb(dot)com> |
| Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Postgres hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Isaac Morland" <isaac(dot)morland(at)gmail(dot)com>, "Jeff Davis" <pgsql(at)j-davis(dot)com> |
| Subject: | Re: [PATCH] Support empty ranges with bounds information |
| Date: | 2021-03-02 20:04:04 |
| Message-ID: | 668b75ad-1c73-4084-838e-1ef5f100d9d5@www.fastmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 2, 2021, at 20:57, Mark Dilger wrote:
> I didn't phrase that clearly enough. I'm thinking about whether you include the bounds information in the hash function. The current implementation of hash_range(PG_FUNCTION_ARGS) is going to hash the lower and upper bounds, since you didn't change it to do otherwise, so "equal" values won't always hash the same. I haven't tested this out, but it seems you could get a different set of rows depending on whether the planner selects a hash join.
I think this issue is solved by the empty-ranges-with-bounds-information-v2.patch I just sent,
since with it, there are no semantic changes at all, lower() and upper() works like before.
/Joel
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chapman Flack | 2021-03-02 20:07:33 | Re: [PATCH] Support empty ranges with bounds information |
| Previous Message | Joel Jacobson | 2021-03-02 20:00:42 | Re: [PATCH] Support empty ranges with bounds information |