Dropping INDEXes in v3.3.3

[adam]

I've read in several places that getting rid of unused INDEXes in Neo is a good way to boost overall database performance.

We are in production on Enterprise Edition v3.3.3. (We are planning to upgrade soon-ish.)

We have identified about 12 INDEXes we are not currently using.

How do we go about a drama-free DROP INDEX ON on our production platform? What are the things we should be looking out for?

This post Neo4j 3.5.0 non-existing index exception after dropping indexes makes me a bit nervous...

[dana_canzano]

For many databases indexes have both benefits and drawbacks. An index can benefit a search, whether that my a Cypher 'match' statement or a SQL 'select' statement. However indexes can also slow an insert/update whether a Cypher 'create (n:Person....or a SQL 'INSERT INTO Person......
But if the index is unused, i.e. its not there for the benefit of the search statements, then yeah removing would at least benefit your insert/updates.

Regarding

This post Neo4j 3.5.0 non-existing index exception after dropping indexes makes me a bit nervous..

there have been many patches to the 3.5.x branch, with the current being 3.5.7. If you are going to move to 3.5.x you would be better served taking the most recent

[adam]

Hey Dana. Thanks!

The CREATE performance improvement is exactly what we're after.

Provided the INDEXes are truly not used, simply dropping them does the trick and one does not need to restart Neo?

Understand completely on jumping to 3.5.7 rather than something earlier.

Related question:

I have to assume that given the nature of uuids this is redundant:

ASSERT pair.uuid IS UNIQUE

Are there any arguments for asserting uniqueness of a UUID?

[dana_canzano]

not sure i understand the last question relative to uniqueness

yes on can create a unique constraint https://neo4j.com/docs/cypher-manual/3.5/schema/constraints/#constraints-create-unique-constraint

is your issue why create said constraint if UUIDs are already guarenteed to be unique already. I guess one can make that assumption but one can also make the assumption that SSN values are unique to a single person but that is not always the case when fraud is involved

[adam]

Hi Dana,

Sorry, but Neo's Fraud Detection use-case examples with self-reported SSNs has nothing to do with my question. Comparing an end-user reported SSN to a UUID is plain silly.

My question is about the trade-off between the extra belt-and-suspenders CONSTRAINT in a uuid (which is mathematically all but assured to be unique to begin with) and the additional database overhead associated with the existence of the constraint.

I resolved my question elsewhere. Thanks.