On 11/01/2014 01:58 PM, Tom Lane wrote:
Andres Freund <and...@2ndquadrant.com> writes:
On 2014-11-01 10:18:03 -0700, Josh Berkus wrote:
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...
Yeah. When we last discussed this, the difficulty was around how to make
that combination work. An unlogged index on an unlogged table is no
problem: the init-fork mechanism is able to make them both go to empty
after a crash. But for an unlogged index on a logged table, just making
the index go to empty is not the correct recovery action.
We'd been wondering how to make crash recovery change the index's pg_index
entry into not indisvalid/indisready status. That's hard to do. But
maybe we don't have to. What about having the init-fork mechanism restore
a hash index into a state with the metapage marked as invalid? hashinsert
etc could simply do nothing when they see this metapage state.
hashgettuple could throw an error saying the index isn't usable until it's
been REINDEXed.
This is not quite as nice as an indisvalid-based solution, because it
requires some extra cooperation from the index AM's code. But setting up
an init fork requires work from the index AM anyway, so that objection
doesn't seem terribly strong to me.
Thoughts?
Isn't the planner still going to try to use the index in that case? If
it's not then I'd be OK with it, but if it's going to make the table
largely unusable until it's reindexed that would be rather sad.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
