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: | Raw Message | Whole Thread | 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 |