Re: Table Partitioning in Postgres:
Jean-Luc Lachance <jllachan@nsd.ca>
From: Jean-Luc Lachance <jllachan@nsd.ca>
To: "Shridhar Daithankar<shridhar_daithankar@persistent.co.in>" <shridhar_daithankar@persistent.co.in>
Cc: "PGSQL General (E-mail)" <pgsql-general@postgresql.org>
Date: 2003-02-19T22:14:25Z
Lists: pgsql-general
Shridhar, I think you missed the most important point. Regardless of the hardware, having a large table partitioned (not necessarely split across multiple discs) on a particular keyfield will improve performance when that keyfield is involved in the query. "Shridhar Daithankar" wrote: > > On Wednesday 19 Feb 2003 12:24 am, you wrote: > > Shridhar, > > > > I must disagree with "that's is an OS's job". > > OSs try to be generic. With databases, we know more about the data > > structure. > > > > If a large table could be split (partitioned) based on specific key, we > > could expect huge improvements for agregates queries for example when > > that key is involved. > > Well, you can create a base table and inherit four or five of them. But that > does not solve the problem really, because postgresql as such does not > support different disk storage area that granularly. > > > Also, DBA must be able to place table on different file systems. They > > know more about the application than the OS does. > > Certainly. But the advantage will not be visible unless you put it on a disk > that is on separate IDE or SCSI channel. Now that you have a large database, > are you using more than one SCSI channel? Otherwise just putting on different > disks will not help as much. > > > Even Postgresql has to be told to perform vaccum and analyze. > > If the OS had enough intelligence we could trust it to do a good job, > > but until then ... > > Partially true. Postgresql could have done vacuum at runtime at the cost od > performance. So developers delegated the task to admin. > > Looking for a solution in problem, the real benefits won't be visible unless > you put it on a different disk channel. Otherwise RAID is your best bait now > as OS can handle it intelligently and it enhances the IO bandwidth immensely. > > Other than that you can not do much with postgresql right now. > > Shridhar > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org