| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, David Fetter <david(at)fetter(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Spilling hashed SetOps and aggregates to disk |
| Date: | 2018-06-11 17:59:35 |
| Message-ID: | 9584.1528739975@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> Also, I am not sure we should really be designing around data types
> where it makes sense to group and then don't supply a btree opclass.
> Seems like they are likely to hit a problem soon anyway.
It's not that unreasonable to have a hash opclass and no btree opclass;
the datatype might not have a natural linear ordering.
But in any case, I think Robert's point was that he'd prefer to avoid
having a poorly-tested special-case code path for that situation, which
seems like a good idea independently of performance considerations.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2018-06-11 18:13:45 | Re: Spilling hashed SetOps and aggregates to disk |
| Previous Message | Jeff Davis | 2018-06-11 17:50:31 | Re: Spilling hashed SetOps and aggregates to disk |