database-indexes

I am trying to implement a database index based on the data structure (B link tree) and algorithms suggested by Lehman and Yao in this paper . In page 2, the authors state that: The disk is partitioned in sections of fixed size (physical pages; in this paper, these correspond to the nodes of the tree). These are the only units that can be read or written by a process. [emphasis mine] (...) (...) a process is allowed to lock and unlock a disk page. This lock gives that process exclusive modification rights to that page; also, a process must have a page locked in order to modify that page. (...)

I have a simple query to join two tables that's being really slow. I found out that the query plan does a seq scan on the large table email_activities (~10m rows) while I think using indexes doing nested loops will actually be faster. I rewrote the query using a subquery in an attempt to force the use of index, then noticed something interesting. If you look at the two query plans below, you will see that when I limit the result set of subquery to 43k, query plan does use index on email_activities while setting the limit in subquery to even 44k will cause query plan to use seq scan on email

I have read in the latest release that super columns are not desirable due to "performance issues", but no where is this explained. Then I read articles such as this one that give wonderful indexing patterns using super columns. This leave me with no idea of what is currently the best way to do indexing in Cassandra. What are the performance issues of super columns? Where can I find current best practices for indexing? jericevans Super columns suffer from a number of problems, not least of which is that it is necessary for Cassandra to deserialze all of the sub-columns of a super column when

I'm undecided whether it's better, performance-wise, to use a very commonly shared column value (like Country ) as partition key for a compound primary key or a rather unique column value (like Last_Name ). Looking at Cassandra 1.2's documentation about indexes I get this: " When to use an index : Cassandra's built-in indexes are best on a table having many rows that contain the indexed value. The more unique values that exist in a particular column, the more overhead you will have, on average, to query and maintain the index. For example, suppose you had a user table with a billion users and

Imagine a table with multiple columns, say, id, a, b, c, d, e . I usually select by id , however, there are multiple queries in the client app that uses various conditions over subsets of the columns. When MySQL executes a query on a single table with multiple WHERE conditions on multiple columns, can it really make use of indexes created on different columns? Or the only way to make it fast is to create multi-column indexes for all possible queries? Yes, MySQL can use multiple index for a single query. The optimizer will determine which indexes will benefit the query. You can use EXPLAIN to

I am creating a new Neo4j database. I have a type of node called User and I would like an index on the properties of user Identifier and EmailAddress . How does one go setting up an index when the database is new? I have noticed in the neo4j.properties file there looks to be support for creating indexes. However when I set these as so # Autoindexing # Enable auto-indexing for nodes, default is false node_auto_indexing=true # The node property keys to be auto-indexed, if enabled node_keys_indexable=EmailAddress,Identifier And add a node and do a query to find an Identifier that I know exists