Re: Table Partitioning in Postgres:

From: Jean-Luc Lachance <jllachan(at)nsd(dot)ca>
To: "Shridhar Daithankar<shridhar_daithankar(at)persistent(dot)co(dot)in>" <shridhar_daithankar(at)persistent(dot)co(dot)in>
Cc: "PGSQL General (E-mail)" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Table Partitioning in Postgres:
Date: 2003-02-19 22:14:25
Message-ID: 3E5401C1.AC4F4086@nsd.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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(at)postgresql(dot)org

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jonathan Bartlett 2003-02-19 22:27:04 Re: BLOB or BYTEA field
Previous Message Andrew Sullivan 2003-02-19 21:52:31 Re: How do I upgrade or coexist PostgreSQL on a Cobalt XTR system?