I want to thank everybody who attended my session “Deep Dive in PostgreSQL Indexes” in Austin. It was quite a wonderful experience! To cover a bigger audience, I also did a webinar on the same topic. There were many questions in that webinar, but unfortunately, there was not enough time to cover each and every question, so I decided to have a followup Q&A session with a blog post on the topic.
The recording and slides are available here. Below is the list of your questions.
The functional index is when an index is defined on the result of a function. This is present in PostgreSQL 7. In later releases of PostgreSQL, you can define the index on the result of an expression. The expression can be any PostgreSQL expression. The function is a subset of expression.
Yes, if all selected columns are in the index, then index-only-scans will be used.
Yes, that’s true that is hard to choose, but it all depends on your data and queries types. I have mentioned recommendations in my slides. There is no mechanism for that in PostgreSQL.
No, it’s optimizer’s responsibility to choose between defined the indexes. Believe that the PostgreSQL optimizer will choose the best option for you.
A date data type is mostly aligned with physical storage. If you are not making many updates and delete operations, then go for the BRIN. But if you have too many updates and deletes, then B-TREE is best for you.
Time is also aligned with physical storage on disk, please see the answer for Q5 above.
Optimizer calculates the cost of each plan and chooses the best based on the cost.
You can check the size of an index. Index bloat detecting is a technique. You can check PostgreSQL wiki https://wiki.postgresql.org/wiki/Index_Maintenance
PostgreSQL offers CLUSTER INDEX using which we can store the data of a table in the order of an Index. However, upon updates/deletes, the data has to be re-clustered to put back in the order of the specified index. However, all the features offered by a clustered index in Oracle are not possible.
If you want to see the comparison of Elasticsearch and PostgreSQL full search text, both are based on inverted indices. I don’t think there should be any significant performance difference, but I don’t have the numbers.
No, B-TREE index is default in PostgreSQL.
According to the documentation, hash performs better for the equality operator. In my opinion, if the column size is bigger then hash perform better than B-TREE, but in the case of smaller size index column B-TREE works better.
It’s not a matter of choice, there are some cases where you can only use GIN, and B-TREE will not work. There is an example in the slides for the same.
Once again thank you, everybody, for attending the session. If you still have any questions, do attend my session in PostgreSQL Beijing, or write the question in the comment section.
Resources
RELATED POSTS