Re: Let's drop two obsolete features which are bear-traps for novices
От | Andrew Dunstan |
---|---|
Тема | Re: Let's drop two obsolete features which are bear-traps for novices |
Дата | |
Msg-id | 545522AE.9060602@dunslane.net обсуждение исходный текст |
Ответ на | Re: Let's drop two obsolete features which are bear-traps for novices (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Let's drop two obsolete features which are bear-traps
for novices
|
Список | pgsql-hackers |
On 11/01/2014 01:26 PM, Andres Freund wrote: > On 2014-11-01 10:18:03 -0700, Josh Berkus wrote: >> On 10/31/2014 03:07 PM, Tom Lane wrote: >>> I don't care one way or the other about the money type, but I will defend >>> hash indexes, especially seeing that we've already added a pretty >>> in-your-face warning as of 9.5: >>> >>> regression=# create table foo(f1 int); >>> CREATE TABLE >>> regression=# create index on foo using hash (f1); >>> WARNING: hash indexes are not WAL-logged and their use is discouraged >>> CREATE INDEX >> Yes, and I'm arguing that is the wrong decision. If hash indexes are >> "discouraged", then they shouldn't be in core in the first place. > Last time we discussed it there were people (IIRC Andrew was one of > them) commenting that they use hash indexes *precisely* because they're > not WAL logged and that they can live with the dangers that creates. I > don't think that's sufficient justification for introducing the feature > at all. But it's nothing new that removing a feature has to fit quite > different criteria than adding one. > > So, by that argument we could remove hash indexes once we have unlogged > indexes on logged tables. But then there's no need to remove them > anymore... > Yes, although there might not be much reason to use them either. I think Tom's first step of making hash indexes automatically unlogged makes sense. Longer term I'd like to see unlogged as an option for all AMs - especially btree. It makes plenty of sense to me to be able to make the data resilient even if the indexes, which can after all be recreated in the unlikely event of a crash, are not. cheers andrew
В списке pgsql-hackers по дате отправления: