Hi Ondrej, Your solution has occurred to me, and wil even work in some cases. But in more advanced queries, where for example, I would need the group ID again to do some window function magic, this will sadly not work, without again doing a reverse lookup to the ref_table to find it again. This scheme might still be faster though even though it would take more queries. Im now testing some of queries against a non-paritioned version of our dataset to see what the difference is. I'm wondering how much the insert performance wil be impacted when not-paritioning our data. We do have a few indexes and constriants on these tables, but not whole lot. I'll so some measurements to see how this wil work out. The general dilemma would be as follows: What if the suggested max of 100 partions would mean that a partition table will also not fit into memory efficiently, and/or that the access pattern is such that because of the query planner, it needs to work it's way though all the partitions for virtually most of the serious queries being done on the data set. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Partitions-and-joins-lead-to-index-lookups-on-all-partitions-tp5055965p5058853.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
