Greetings,
* Arya F (arya6000@gmail.com) wrote:
> I need to store about 600 million rows of property addresses across
> multiple counties. I need to have partitioning setup on the table as
> there will be updates and inserts performed to the table frequently
> and I want the queries to have good performance.
That's not what partitioning is for, and 600m rows isn't all *that*
many.
> >From what I understand hash partitioning would not be the right
> approach in this case, since for each query PostgreSQL has to check
> the indexes of all partitions?
>
> Would list partitioning be suitable? if I want PostgreSQL to know
> which partition the row is it can directly load the relevant index
> without having to check other partitions. Should I be including the
> partition key in the where clause?
>
> I'd like to hear some recommendations on the best way to approach
> this. I'm using PostgreSQL 12
In this case, it sounds like "don't" is probably the best option.
Partitioning is good for data management, particularly when you have
data that "ages out" or should be removed/dropped at some point,
provided your queries use the partition key. Partitioning doesn't speed
up routine inserts and updates that are using a proper index and only
updating a small set of rows at a time.
Thanks,
Stephen
