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