X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 1967011F60E5 for ; Wed, 26 Apr 2006 17:49:03 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 99245-10 for ; Wed, 26 Apr 2006 17:48:52 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from stash.illumen.com (unknown [64.207.29.137]) by postgresql.org (Postfix) with ESMTP id B5A8C11F60B1 for ; Wed, 26 Apr 2006 17:48:51 -0300 (ADT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66972.D27A95DD" Subject: Re: Table partitioning X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 26 Apr 2006 14:48:50 -0600 Message-ID: <8511B4970E0D124898E973DF496F9B432515CC@stash.stackdump.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ADMIN] Table partitioning Thread-Index: AcZpcKGu5bVXxGFHTr+kvJjLQ7bE9QAAYHrw From: "Benjamin Krajmalnik" To: "Chris Hoover" Cc: X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200604/286 X-Sequence-Number: 21455 This is a multi-part message in MIME format. ------_=_NextPart_001_01C66972.D27A95DD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, right now there is no data in those partitions. All of the data is currently in the parent table (I have not yet created the trigger which will route the data to the correct partition). I just found to items intriguing - first, that the indices and other properties other than the field definition were not inherited (is this how this is supposed to work?), and second, that PG first retrieves the entire result set and then limits it (or at least that appear to be how it is working). If the order by clause were an expression, I can understand where it would have to first retrieve the entire resultset and then limit it. However, when we are dealing with an order by clause running on an index or primary key, I would figure that it would only retrieve the number of rows limited, or if an offset is specified then go to the offset and only process the "limit" number of rows. =20 =20 ________________________________ From: Chris Hoover [mailto:revoohc@gmail.com]=20 Sent: Wednesday, April 26, 2006 2:33 PM To: Benjamin Krajmalnik Cc: pgsql-admin@postgresql.org Subject: Re: [ADMIN] Tale partitioning =20 Each of the partition tables needs it's own set of indexes. Build them, and see if the does not fix your performance issues. Also, be sure you turned on the constraint_exclusion parameter, and each table (other than the "master") has an constraint on it that is unique.=20 HTH, Chris ------_=_NextPart_001_01C66972.D27A95DD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually, right now there is no = data in those partitions.

All of the data is currently in the = parent table (I have not yet created the trigger which will route the data to = the correct partition).

I just found to items intriguing = – first, that the indices and other properties other than the field = definition were not inherited (is this how this is supposed to work?), and second, = that PG first retrieves the entire result set and then limits it (or at least = that appear to be how it is working).

If the order by clause were an = expression, I can understand where it would have to first retrieve the entire = resultset and then limit it.  However, when we are dealing with an order by = clause running on an index or primary key, I would figure that it would only retrieve the = number of rows limited, or if an offset is specified then go to the offset and = only process the “limit” number of rows.

 

 

From: Chris = Hoover [mailto:revoohc@gmail.com]
Sent: Wednesday, April = 26, 2006 2:33 PM
To: Benjamin = Krajmalnik
Cc: = pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Tale partitioning

 

Each of the = partition tables needs it's own set of indexes.  Build them, and see if the = does not fix your performance issues.  Also, be sure you turned on the constraint_exclusion parameter, and each table (other than the "master") has an constraint on it that is unique.

HTH,

Chris


------_=_NextPart_001_01C66972.D27A95DD--