| From: | Stephen Frost <sfrost(at)snowman(dot)net> | 
|---|---|
| To: | Hannu Krosing <hannu(at)krosing(dot)net> | 
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: record identical operator | 
| Date: | 2013-10-04 01:09:59 | 
| Message-ID: | 20131004010959.GV2706@tamriel.snowman.net | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
* Hannu Krosing (hannu(at)krosing(dot)net) wrote:
> The main exposed implementation detail of this operator is that it is
> very fast and can be recommended to be used at user level for speeding
> up equal query like this
> 
> SELECT * FROM t WHERE <guaranteed equal> or <equal>
> 
> where the plain <equal> will only be called when fast <guaranteed equal>
> fails.
Yeah, this would be exactly the kind of misuse that we will need to be
prepared to support with these new operators.  If this is actually
faster/better/whatever, then we should be implementing it in our
conditional handling, not encouraging users to create hacks like this.
> a bit similar to how you can cut down on index size on long text fields by
> indexing their hashes and then querying
> 
> SELECT * FROM t
>  WHERE hashtext(verylongtext) = hashtext(sample)
>     AND verylongtext = sample
This case clearly requires a great deal more thought and consideration
on the DBA's side and is also a lot more obvious what it's doing than
having 'where x *= 123 or x = 123'.
Thanks,
		Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2013-10-04 01:36:21 | Re: Any reasons to not move pgstattuple to core? | 
| Previous Message | Robert Haas | 2013-10-04 00:51:08 | Re: GSOC13 proposal - extend RETURNING syntax |