28 ms·

I’m loving all the Postgres submissions on HN over the last couple days. My professional experience is mostly with Redshift which is only Postgres-like. I was

by mulmen 5y ago

I’m loving all the Postgres submissions on HN over the last couple days. My professional experience is mostly with Redshift which is only Postgres-like. I was not aware of BRIN indexes. Am I correct in assuming those are suitable for analytical workloads? Is the data implicitly sorted in a BRIN index or is there a mechanism to optimize the storage layer for BRIN indexed data?

luhn 5y ago
BRIN indexes don't affect the storage layer, so you need to make sure your table is appropriately sorted on disk through other means. CLUSTER can do this as a one-off job (pg_repack if you need to keep the table available for writes), but won't sort new data as it's written. https://www.postgresql.org/docs/current/sql-cluster.html https://www.postgresql.org/docs/current/sql-cluster.html https://reorg.github.io/pg_repack/ https://reorg.github.io/pg_repack/
- mulmen 5y ago
  Very cool, thanks for sharing. I'm curious how far vanilla Postgres can be taken for analytics before more exotic columnar solutions like Redshift start to make sense.
- throwaway8456 5y ago
  For all of its greatness and (mostly well deserved) praises, the lack of a reasonable cluster index capability (as in data order at storage layer) is Postgres' biggest limit IMHO. Unfortunately, The CLUSTER command not only "blocks" the table for WRITE ops, but more importantly, it also blocks READ operations [0]. pg_repack helps, but is not always available when using a managed PG offering. Not being able to control data ordering on disk is a potential deal breaker once the data reaches a certain size. [0]: https://www.postgresql.org/docs/current/sql-cluster.html https://www.postgresql.org/docs/current/sql-cluster.html
  - deleted 5y ago
    [deleted]
  - edoceo 5y ago
    Any idea what that size is? When should one be worried?
    - throwaway8456 5y ago
      It depends on a lot of factors, my unscientific rule of thumb is that if the data doesn't fit in the RAM of the server, then that's when you may start worrying about how the data will be fetched from the disk when you query it (if performance matters). The problem case is when the data needed to serve an average query is "scattered across the disk". This means that you will need to potentially fetch way more information from the disk (because data is returned by blocks/pages, not by bytes) than necessary to fulfill the query. A worst case example: say to compute a query, you need to get 5000 rows (with a size of 100 bytes per row, 500KB in net total), if they are "perfectly scattered" (i.e. each row on a different page), you will really need to bring in 5000 pages of 8KB per page (default page size in Postgres) for a total of 40MB. By fetching 80 times more data than needed, you've essentially reduced your throughput by 80x. Note that the example above assumes that an index (e.g. btree) can be leveraged. The index would point directly to the numerous pages, which is likely still much better compared to doing a full scan. But that index doesn't solve all your problems, only part 1. It may not be a big deal as bringing 40MB from a disk would go fast, but this will limit 1) the number of concurrent user you'll be able to serve, 2) if you need 100,000 rows instead of 5000, then your query will take longer to process and it may be negatively noticeable by your user. If you can co-locate the data on the disk (i.e. put them on same or contiguous pages) deterministically, then you would feel much better about your throughput. Cluster Index (or Indexed Views as it's called in SQL Server) is the typical mechanism to sort the data on the disk in RDBMS. MySQL does that by default with the primary key, but not Postgres.
      - tomnipotent 5y ago
        > is the typical mechanism to sort the data on the disk in RDBMS SQL Server and Oracle both default to heaps (though it's rare to see a SQL Server table without a clustered index).
haimez 5y ago
Not an expert, but have played with BRIN indices on a much older version of Postgres. Some of my experience may be misremembered or out of date. You are correct that they can be used for analytical workloads (but not exclusively, you still have other index types available and transactions, etc). They have very little performance overhead for the write path and small memory footprint compared to B-tree indexes. However, they are only effective for improving read performance when filtering a table with a selective predicate, and even then- only if there’s some temporal relationship between the indexed column values and the time that the rows are inserted. Auto incrementing id and created_at columns work great at this. So to your second point, no- I don’t believe there’s any specific storage layer awareness of them. However, Postgres inserts are typically at the “tail” of the table as a consequence of the MVCC implementation (although, tables with frequent deletes and updates can be confounding to the effectiveness of BRINs). Remember though that the correlation needn’t be perfect to be very effective. If you can limit what would otherwise be a full table scan + filter evaluation to a scan + filter of a handful of pages that “might” contain matching rows, that can be a huge performance boost with a tiny cost of maintaining the index.
- mulmen 5y ago
  Interesting, thanks for sharing. I am comparing this mentally to Redshift's sort keys. It sounds like a BRIN index might approximate that behavior for the time dimension but not for a locale dimension (integer value, low cardinality, high volume). Do BRIN indices support compound keys? Sounds like that may not even be desirable even if they do. With a Postgres analytic table that has a time and locale dimension it sounds like a hybrid of a BRIN index on the time dimension and then partition on the locale, which probably manifests as an inherited table. But that would require some contortions in the ETL layer to re-write the partitions in order when they are updated, and to create and drop the new partitions as necessary.
  - haimez 5y ago
    I don’t see any reason why it couldn’t support compound keys, assuming the combined min/max definition is in index column defined order. I have no idea if the Postgres implementation does though. You’re also correct that a compound BRIN is questionably useful. If the first column in the key isn’t already an effective filter, you’re going to have to scan the whole table anyway in most cases- and if it is, then the cost of storing the min/max of subsequent columns is going to increase the overhead of the BRIN index in a way that seems unlikely to justify the benefit. It seems to me that the indexed columns would have to be mutually correlating in sort order for that to be useful (eg: created_date, created_time)
timando 5y ago
A BRIN index is basically a minimum and maximum value in the indexed column for each megabyte of table.
- jambalaya 5y ago
  Had a question and curious if you know. Could an updated_at column work theoretically better than a created_at column if there are some deletes and updates? Would updated_at be ordered as they are on disk?

by mulmen 5y ago

luhn 5y ago

BRIN indexes don't affect the storage layer, so you need to make sure your table is appropriately sorted on disk through other means. CLUSTER can do this as a one-off job (pg_repack if you need to keep the table available for writes), but won't sort new data as it's written. https://www.postgresql.org/docs/current/sql-cluster.html https://www.postgresql.org/docs/current/sql-cluster.html https://reorg.github.io/pg_repack/ https://reorg.github.io/pg_repack/

mulmen 5y ago
Very cool, thanks for sharing. I'm curious how far vanilla Postgres can be taken for analytics before more exotic columnar solutions like Redshift start to make sense.
throwaway8456 5y ago
For all of its greatness and (mostly well deserved) praises, the lack of a reasonable cluster index capability (as in data order at storage layer) is Postgres' biggest limit IMHO. Unfortunately, The CLUSTER command not only "blocks" the table for WRITE ops, but more importantly, it also blocks READ operations [0]. pg_repack helps, but is not always available when using a managed PG offering. Not being able to control data ordering on disk is a potential deal breaker once the data reaches a certain size. [0]: https://www.postgresql.org/docs/current/sql-cluster.html https://www.postgresql.org/docs/current/sql-cluster.html
- deleted 5y ago
  [deleted]
- edoceo 5y ago
  Any idea what that size is? When should one be worried?
  - throwaway8456 5y ago
    It depends on a lot of factors, my unscientific rule of thumb is that if the data doesn't fit in the RAM of the server, then that's when you may start worrying about how the data will be fetched from the disk when you query it (if performance matters). The problem case is when the data needed to serve an average query is "scattered across the disk". This means that you will need to potentially fetch way more information from the disk (because data is returned by blocks/pages, not by bytes) than necessary to fulfill the query. A worst case example: say to compute a query, you need to get 5000 rows (with a size of 100 bytes per row, 500KB in net total), if they are "perfectly scattered" (i.e. each row on a different page), you will really need to bring in 5000 pages of 8KB per page (default page size in Postgres) for a total of 40MB. By fetching 80 times more data than needed, you've essentially reduced your throughput by 80x. Note that the example above assumes that an index (e.g. btree) can be leveraged. The index would point directly to the numerous pages, which is likely still much better compared to doing a full scan. But that index doesn't solve all your problems, only part 1. It may not be a big deal as bringing 40MB from a disk would go fast, but this will limit 1) the number of concurrent user you'll be able to serve, 2) if you need 100,000 rows instead of 5000, then your query will take longer to process and it may be negatively noticeable by your user. If you can co-locate the data on the disk (i.e. put them on same or contiguous pages) deterministically, then you would feel much better about your throughput. Cluster Index (or Indexed Views as it's called in SQL Server) is the typical mechanism to sort the data on the disk in RDBMS. MySQL does that by default with the primary key, but not Postgres.
    - tomnipotent 5y ago
      > is the typical mechanism to sort the data on the disk in RDBMS SQL Server and Oracle both default to heaps (though it's rare to see a SQL Server table without a clustered index).

haimez 5y ago

Not an expert, but have played with BRIN indices on a much older version of Postgres. Some of my experience may be misremembered or out of date. You are correct that they can be used for analytical workloads (but not exclusively, you still have other index types available and transactions, etc). They have very little performance overhead for the write path and small memory footprint compared to B-tree indexes. However, they are only effective for improving read performance when filtering a table with a selective predicate, and even then- only if there’s some temporal relationship between the indexed column values and the time that the rows are inserted. Auto incrementing id and created_at columns work great at this. So to your second point, no- I don’t believe there’s any specific storage layer awareness of them. However, Postgres inserts are typically at the “tail” of the table as a consequence of the MVCC implementation (although, tables with frequent deletes and updates can be confounding to the effectiveness of BRINs). Remember though that the correlation needn’t be perfect to be very effective. If you can limit what would otherwise be a full table scan + filter evaluation to a scan + filter of a handful of pages that “might” contain matching rows, that can be a huge performance boost with a tiny cost of maintaining the index.

mulmen 5y ago
Interesting, thanks for sharing. I am comparing this mentally to Redshift's sort keys. It sounds like a BRIN index might approximate that behavior for the time dimension but not for a locale dimension (integer value, low cardinality, high volume). Do BRIN indices support compound keys? Sounds like that may not even be desirable even if they do. With a Postgres analytic table that has a time and locale dimension it sounds like a hybrid of a BRIN index on the time dimension and then partition on the locale, which probably manifests as an inherited table. But that would require some contortions in the ETL layer to re-write the partitions in order when they are updated, and to create and drop the new partitions as necessary.
- haimez 5y ago
  I don’t see any reason why it couldn’t support compound keys, assuming the combined min/max definition is in index column defined order. I have no idea if the Postgres implementation does though. You’re also correct that a compound BRIN is questionably useful. If the first column in the key isn’t already an effective filter, you’re going to have to scan the whole table anyway in most cases- and if it is, then the cost of storing the min/max of subsequent columns is going to increase the overhead of the BRIN index in a way that seems unlikely to justify the benefit. It seems to me that the indexed columns would have to be mutually correlating in sort order for that to be useful (eg: created_date, created_time)

timando 5y ago

A BRIN index is basically a minimum and maximum value in the indexed column for each megabyte of table.

jambalaya 5y ago
Had a question and curious if you know. Could an updated_at column work theoretically better than a created_at column if there are some deletes and updates? Would updated_at be ordered as they are on disk?