Re: Table Partitioning in Postgres:

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