Correct Concept On Table Partition - Mailing list pgsql-general

From Yan Cheng Cheok
Subject Correct Concept On Table Partition
Date
Msg-id 314323.29581.qm@web65706.mail.ac4.yahoo.com
Whole thread Raw
Responses Re: Correct Concept On Table Partition  ("A. Kretschmer" <andreas.kretschmer@schollglas.com>)
List pgsql-general
Currently, I plan to use table partition to solve the following problem.

I have a table which is going to grow to a very huge row, as time goes on.

As I know, as table grow larger, the read operation will be slower.

Hence, I decide to use table partition, in order to improve read speed.

I have parent table named measurement.

Then I will have child tables named measurement_1, measurement_2, ....

First 1st millions rows will be write to measurement_1, 2nd millions into measurement_2, ....

My understanding is,

(1) measurement table will act as a virtual table, which make me easy for me to perform query read and query write.

(2) measurement_1, measurement_2 will be "real" table.

(3) when viewing the 2nd millions row (1,000,001 - 2,000,000) of measurement,

before partition
================
instead of reading total 2 millions row, and displaying the (1,000,001 - 2,000,000)

after partition
===============
we will just need to access table measurement_2 only, which is smaller, and shall be faster.

(4) extensive join operation will be involve. I am more concern into read speed.


Is this the correct expectation, on table partition?

Thanks and Regards
Yan Cheng CHEOK





pgsql-general by date:

Previous
From: Yan Cheng Cheok
Date:
Subject: Primary Key Increment Doesn't Seem Correct Under Table Partition
Next
From: Alban Hertroys
Date:
Subject: Re: Primary Key Increment Doesn't Seem Correct Under Table Partition