| 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 |