On May 15, 2014, at 21:07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> On Thu, May 15, 2014 at 05:20:35PM +0200, Olivier Macchioni wrote:
>>> I guess my best bet is to replace it by another kind of indexes... =
and maybe one day PostgreSQL will be clever enough to issue a warning / =
error in such a case for the people like me who don't read *all the doc* =
:P
>=20
>> Yes, streaming replication has made our hash indexes even worse. In =
the
>> past, I have suggested we issue a warning for the creation of hash
>> indexes, but did not get enough agreement.
>=20
> Mainly because it wouldn't be a very helpful message.
>=20
> I wonder though if we could throw a flat-out error for attempts to use
> a hash index on a hot standby server. That would get people's =
attention
> without being mere nagging in other situations. It's not a 100% =
solution
> because you'd still lose if you tried to use a hash index on a slave
> since promoted to master. But it would help without being a large
> sink for effort.
>=20
> regards, tom lane
I am not aware of the technical implementation hurdles, but in this case =
any of the following behaviors would have been better for me:
- still perform the query, without using the index (preferably issuing a =
warning of some kind)
- Tom's solution - refuse to perform the query, with a clear error =
message (looking at the error, I thought I had a broken replication, =
it's clearly not a nice message to have)
- (possibly replace on-the-fly any hash index by another kind of indexes =
on the slave when setting up the replication or creating the index on =
the master? does this even make sense?)
- somehow disallow to setup of streaming replication when there is a =
hash index in any DB / and refuse the creation of a hash index on a =
master server, so we don't reach this situation
- I assume there is a usage for hash indexes and we don't simply want to =
deprecate them
Olivier=
