Unconventional PostgreSQL Optimizations

(hakibenita.com)

77 points | by haki 3 hours ago

5 comments

  • sc68cal 48 minutes ago
    Great article, shows a lot of interesting PostgreSQL features. I have used PostgreSQL and MySQL for decades, and this article showed me that I have barely scratched the surface of what is possible.
  • lasgawe 13 minutes ago
    some points from this article that I didn't know before.
  • pksunkara 1 hour ago
    I think a stored generated column allows you to create an index on it directly. Isn't it better approach?
    • tczMUFlmoNk 1 hour ago
      The article explains why they want to avoid this option:

      > Starting at version 14, PostgreSQL supports generated columns - these are columns that are automatically populated with an expression when we insert the row. Sounds exactly like what we need but there is a caveat - the result of the expression is materialized - this means additional storage, which is what we were trying to save in the first place!

      • pksunkara 54 minutes ago
        Thanks, missed that part. I would still be interested in knowing how much additional storage that adds, if the OP is interested in updating the article.
    • zenmac 33 minutes ago
      >I think a stored generated column allows you to create an index on it directly. Isn't it better approach?

      Is it also possible to create index (maybe partial index) on expressions?

    • rpsw 1 hour ago
      I assume it would increase the storage usage, which they say they are trying to avoid in that example.
  • OptionOfT 1 hour ago
    Remarkably fresh content.

    It's interesting how both virtual columns and hash indexes work, but feel like they're bolted on, vs being made part of the whole ecosystem so that they work seamlessly.

  • SigmundA 18 minutes ago
    >Currently, constraint exclusion is enabled by default only for cases that are often used to implement table partitioning via inheritance trees. Turning it on for all tables imposes extra planning overhead that is quite noticeable on simple queries, and most often will yield no benefit for simple queries.

    PG's lack of plan caching strikes again, this sort of thing is not a concern in other DB's that reuse query plans.