Re: record identical operator

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

In response to

Browse pgsql-hackers by date

  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