Is this being done because it can be, or is it solving a real-life pain
point? Just wondering what the perspective is here.
Much of partitioning strategy seems to me to revolve around how the system
is used, and not just the schema and what is possible. For instance, you
can mimic primary and fore
Well, if u have 10M rows, and all your queries use the same column in the
query and the data can split pretty even between the partitions, any
specific reason not to use is ? An index will help u reach a complexity of
(logn) while partition + index can be in complexity of (logm) when m = rows
in pa
>
> All the queries uses the vendor product and thats why this column is a
> perfect fit as a partition column.
> My main table is big (10M+) (Product), but other tables can also be
> big(1M+)..
>
I assume you have query performance problems and are hoping partitioning
will help? Are you read heav
Hey Michael,
first of all thanks for the quick response.
Right now the production env is on a different version(10). I'm doing all
my tests on a test environment. I'm familiar with the hash partitions but
my queries doesnt involve the product.id therefore iti isnt relevant. All
the queries uses the
How many rows are you dealing with currently? What are your queries like?
Have you looked at doing a hash partition on product.id? Is this on a test
system or destined for a production environment in the near future? I ask
because PG12 is still in beta.
Hey,
Thanks to the new partitions features in pg12 (referencing partition table
is possible) I was trying to migrate some of my tables into a partitions
structure.
Lets assume I have the following non partitions structure :
Product(id int PK,vendor int references Vendor(id),price int)
ProductPic(
