pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedPartitioning
33+ messages / 22 participants
[nested] [flat]
* Partitioning
@ 2004-09-15 21:09 J. Andrew Rogers <jrogers@neopolitan.com>
2004-09-16 03:55 ` Re: Partitioning Greg Stark <gsstark@mit.edu>
2004-09-16 20:39 ` Re: Partitioning Jim C. Nasby <decibel@decibel.org>
0 siblings, 2 replies; 33+ messages in thread
From: J. Andrew Rogers @ 2004-09-15 21:09 UTC (permalink / raw)
To: pgsql-performance
On Tue, 2004-09-14 at 21:30, Joe Conway wrote:
> That's exactly what we're doing, but using inherited tables instead of a
> union view. With inheritance, there is no need to rebuild the view each
> time a table is added or removed. Basically, in our application, tables
> are partitioned by either month or week, depending on the type of data
> involved, and queries are normally date qualified.
We do something very similar, also using table inheritance and a lot of
triggers to automatically generate partitions and so forth. It works
pretty well, but it is a custom job every time I want to implement a
partitioned table. You can save a lot on speed and space if you use it
to break up large tables with composite indexes, since you can drop
columns from the table depending on how you use it. A big part of
performance gain is that the resulting partitions end up being more
well-ordered than the non-partitioned version, since inserts are hashed
to different partition according to the key and hash function. It is
kind of like a cheap and dirty real-time CLUSTER operation. It also
lets you truncate, lock, and generally be heavy-handed with subsets of
the table without affecting the rest of the table.
I think generic table partitioning could pretty much be built on top of
existing capabilities with a small number of tweaks.
The main difference would be the ability to associate a partitioning
hash function with a table (probably defined inline at CREATE TABLE
time). Something with syntax like:
...PARTITION ON 'date_trunc(''hour'',ts)'...
There would also probably need to be some type of metadata table to
associate specific hashes with partition table names. Other than that,
the capabilities largely already exist, and managing the partition
hashing and association is the ugly part when rolling your own.
Intercepting DML when necessary and making it behave correctly is
already pretty easy, but could probably be streamlined.
j. andrew rogers
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2004-09-15 21:09 Partitioning J. Andrew Rogers <jrogers@neopolitan.com>
@ 2004-09-16 03:55 ` Greg Stark <gsstark@mit.edu>
2004-09-16 10:58 ` Re: Partitioning Mike Rylander <mrylander@gmail.com>
1 sibling, 1 reply; 33+ messages in thread
From: Greg Stark @ 2004-09-16 03:55 UTC (permalink / raw)
To: J. Andrew Rogers <jrogers@neopolitan.com>; +Cc: pgsql-performance
"J. Andrew Rogers" <jrogers@neopolitan.com> writes:
> We do something very similar, also using table inheritance
I have a suspicion postgres's table inheritance will end up serving as a good
base for a partitioned table feature. Is it currently possible to query which
subtable a record came from though?
> A big part of performance gain is that the resulting partitions end up being
> more well-ordered than the non-partitioned version, since inserts are hashed
> to different partition according to the key and hash function. It is kind of
> like a cheap and dirty real-time CLUSTER operation.
There is also one particular performance gain that cannot be obtained via
other means: A query that accesses a large percentage of a single partition
can use a sequential table scan of just that partition. This can be several
times faster than using an index scan which is the only option if all the data
is stored in a single large table.
This isn't an uncommon occurrence. Consider an accounting table partitioned by
accounting period. Any aggregate reports for a single accounting period fall
into this category. If you define your partitions well that can often by most
or all of your reports.
Of course this applies equally if the query is accessing a small number of
partitions. A further refinement is to leverage the partitioning in GROUP BY
or ORDER BY clauses. If you're grouping by the partition key you can avoid a
large sort without having to resort to an index scan or even a hash. And of
course it's tempting to think about parallelization of such queries,
especially if the partitions are stored in separate table spaces on different
drives.
> It also lets you truncate, lock, and generally be heavy-handed with subsets
> of the table without affecting the rest of the table.
The biggest benefit by far is this management ability of being able to swap in
and out partitions in a single atomic transaction that doesn't require
extensive i/o.
In the application we used them on Oracle 8i they were an absolute life-saver.
They took a huge batch job that took several days to run in off-peak hours and
turned it into a single quick cron job that could run at peak hours. We were
able to cut the delay for our OLTP data showing up in the data warehouse from
about a week after extensive manual work to hours after a daily cron job.
> ...PARTITION ON 'date_trunc(''hour'',ts)'...
>
> There would also probably need to be some type of metadata table to
> associate specific hashes with partition table names. Other than that,
> the capabilities largely already exist, and managing the partition
> hashing and association is the ugly part when rolling your own.
> Intercepting DML when necessary and making it behave correctly is
> already pretty easy, but could probably be streamlined.
I would suggest you look at the Oracle syntax to handle this. They've already
gone through several iterations of implementations. The original Oracle 7
implementation was much as people have been describing where you had to define
a big UNION ALL view and enable an option to have the optimizer look for such
views and attempt to eliminate partitions.
In Oracle 8i they introduced first class partitions with commands to define
and manipulate them. You defined a high bound for each partition.
In Oracle 9 (or thereabouts, sometime after 8i at any rate) they introduced a
new form where you specify a specific constant value for each partition. This
seems to be more akin to how you're thinking about things.
The optimizer has several plan nodes specific for partitioned tables. It can
select a single known partition based on information present in the query. It
can also detect cases where it can be sure the query will only access a single
partition but won't be able to determine which until execution time based on
placeholder parameters for cases like "WHERE partition_key = ?". It can also
detect cases like "WHERE partition_key between ? and ?" and "WHERE
partition_key IN (?,?,?)" Or join clauses on partitions. It can also do some
magic things with "GROUP BY partition_key" and "ORDER BY partition_key".
The work in the optimizer will be the most challenging part. In an ideal world
if the optimizer is very solid it will be possible to bring some partitions to
slow or even near-line storage media. As long as no live queries accidentally
access the wrong partitions the rest of the database need never know that the
data isn't readily available.
--
greg
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2004-09-15 21:09 Partitioning J. Andrew Rogers <jrogers@neopolitan.com>
2004-09-16 03:55 ` Re: Partitioning Greg Stark <gsstark@mit.edu>
@ 2004-09-16 10:58 ` Mike Rylander <mrylander@gmail.com>
0 siblings, 0 replies; 33+ messages in thread
From: Mike Rylander @ 2004-09-16 10:58 UTC (permalink / raw)
To: Greg Stark <gsstark@mit.edu>; +Cc: pgsql-performance
On 15 Sep 2004 23:55:24 -0400, Greg Stark <gsstark@mit.edu> wrote:
>
> "J. Andrew Rogers" <jrogers@neopolitan.com> writes:
>
> > We do something very similar, also using table inheritance
>
> I have a suspicion postgres's table inheritance will end up serving as a good
> base for a partitioned table feature. Is it currently possible to query which
> subtable a record came from though?
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2004-09-15 21:09 Partitioning J. Andrew Rogers <jrogers@neopolitan.com>
@ 2004-09-16 20:39 ` Jim C. Nasby <decibel@decibel.org>
2004-09-16 21:59 ` Re: Partitioning J. Andrew Rogers <jrogers@neopolitan.com>
1 sibling, 1 reply; 33+ messages in thread
From: Jim C. Nasby @ 2004-09-16 20:39 UTC (permalink / raw)
To: J. Andrew Rogers <jrogers@neopolitan.com>; +Cc: pgsql-performance
On Wed, Sep 15, 2004 at 02:09:31PM -0700, J. Andrew Rogers wrote:
> On Tue, 2004-09-14 at 21:30, Joe Conway wrote:
> > That's exactly what we're doing, but using inherited tables instead of a
> > union view. With inheritance, there is no need to rebuild the view each
> > time a table is added or removed. Basically, in our application, tables
> > are partitioned by either month or week, depending on the type of data
> > involved, and queries are normally date qualified.
>
>
>
> We do something very similar, also using table inheritance and a lot of
> triggers to automatically generate partitions and so forth. It works
> pretty well, but it is a custom job every time I want to implement a
> partitioned table. You can save a lot on speed and space if you use it
> to break up large tables with composite indexes, since you can drop
> columns from the table depending on how you use it. A big part of
Forgive my ignorance, but I didn't think you could have a table that
inherits from a parent not have all the columns. Or is that not what you
mean by 'you can drop columns from the table...'?
This is one advantage I see to a big UNION ALL view; if you're doing
partitioning based on unique values, you don't actually have to store
that value in the partition tables. For example,
http://stats.distributed.net has a table that details how much work each
participant did each day for each project. Storing project_id in that
table is an extra 4 bytes... doesn't sound like much until you consider
that the table has over 130M rows right now. So it would be nice to have
an easy way to partition the table based on unique project_id's and not
waste space in the partition tables on a field that will be the same for
every row (in each partition).
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2004-09-15 21:09 Partitioning J. Andrew Rogers <jrogers@neopolitan.com>
2004-09-16 20:39 ` Re: Partitioning Jim C. Nasby <decibel@decibel.org>
@ 2004-09-16 21:59 ` J. Andrew Rogers <jrogers@neopolitan.com>
0 siblings, 0 replies; 33+ messages in thread
From: J. Andrew Rogers @ 2004-09-16 21:59 UTC (permalink / raw)
To: Jim C. Nasby <decibel@decibel.org>; +Cc: pgsql-performance
On Thu, 2004-09-16 at 13:39, Jim C. Nasby wrote:
> Forgive my ignorance, but I didn't think you could have a table that
> inherits from a parent not have all the columns. Or is that not what you
> mean by 'you can drop columns from the table...'?
>
> This is one advantage I see to a big UNION ALL view; if you're doing
> partitioning based on unique values, you don't actually have to store
> that value in the partition tables. For example,
> http://stats.distributed.net has a table that details how much work each
> participant did each day for each project. Storing project_id in that
> table is an extra 4 bytes... doesn't sound like much until you consider
> that the table has over 130M rows right now. So it would be nice to have
> an easy way to partition the table based on unique project_id's and not
> waste space in the partition tables on a field that will be the same for
> every row (in each partition).
Yeah, it is harder to do this automagically, though in theory it should
be possible. Since we have to roll our own partitioning anyway, we've
broken up composite primary keys so that one of the key columns hashes
to a partition, using the key itself in the partition table name rather
than replicating that value several million times. Ugly as sin, but you
can make it work in some cases.
I do just enough work for our queries to behave correctly, and a lot of
times I actually hide the base table and its descendents underneath a
sort of metadata table that is grafted to the base tables by a lot of
rules/triggers/functions/etc, and then do queries against that or a view
of that. As I said, ugly as sin and probably not universal, but you need
a lot of abstraction to make it look halfway normal. I'm going to think
about this some more and see if I can't construct a generic solution.
cheers,
j. andrew rogers
^ permalink raw reply [nested|flat] 33+ messages in thread
* partitioning
@ 2005-12-13 08:20 Marc Cousin <mcousin@sigma.fr>
2005-12-13 11:40 ` Re: partitioning Pandurangan R S <pandurangan.r.s@gmail.com>
0 siblings, 1 reply; 33+ messages in thread
From: Marc Cousin @ 2005-12-13 08:20 UTC (permalink / raw)
To: pgsql-performance
Hi,
I've been working on trying to partition a big table (I've never partitioned a
table in any other database till now).
Everything went ok, except one query that didn't work afterwards.
I've put the partition description, indexes, etc ..., and the explain plan
attached.
The query is extremely fast without partition (index scan backards on the
primary key)
The query is : "select * from logs order by id desc limit 100;"
id is the primary key.
It is indexed on all partitions.
But the explain plan does full table scan on all partitions.
While I think I understand why it is doing this plan right now, is there
something that could be done to optimize this case ? Or put a warning in the
docs about this kind of behaviour. I guess normally someone would partition
to get faster queries :)
Anyway, I thought I should mention this, as it has been quite a surprise.
Attachments:
partition.txt (text/plain, 5.0K) download
CREATE TABLE logs_150 (CHECK ( id_machine = 150)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_163 (CHECK ( id_machine = 163)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_289 (CHECK ( id_machine = 289)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_319 (CHECK ( id_machine = 319)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_238 (CHECK ( id_machine = 238)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_148 (CHECK ( id_machine = 148)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_176 (CHECK ( id_machine = 176)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_164 (CHECK ( id_machine = 164)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_316 (CHECK ( id_machine = 316)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_313 (CHECK ( id_machine = 313)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_217 (CHECK ( id_machine = 217)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_167 (CHECK ( id_machine = 167)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_287 (CHECK ( id_machine = 287)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_279 (CHECK ( id_machine = 279)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_248 (CHECK ( id_machine = 248)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_280 (CHECK ( id_machine = 280)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_165 (CHECK ( id_machine = 165)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_330 (CHECK ( id_machine = 330)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_149 (CHECK ( id_machine = 149)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_157 (CHECK ( id_machine = 157)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_272 (CHECK ( id_machine = 272)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_311 (CHECK ( id_machine = 311)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_309 (CHECK ( id_machine = 309)) INHERITS (logs) TABLESPACE data_logs;
CREATE TABLE logs_318 (CHECK ( id_machine = 318)) INHERITS (logs) TABLESPACE data_logs;
CREATE UNIQUE INDEX logs_150_pkey ON logs_150 (id) TABLESPACE index_logs;CREATE INDEX date_150 ON logs_150 (date) TABLESPACE index_logs ;CREATE INDEX event_150 ON logs_150 (evenement) TABLESPACE index_logs;
.....
logs=> explain select * from logs order by id desc limit 100;
QUERY PLAN
---------------------------------------------------------------------------------------------
Limit (cost=16524647.29..16524647.54 rows=100 width=295)
-> Sort (cost=16524647.29..16568367.11 rows=17487927 width=295)
Sort Key: public.logs.id
-> Result (cost=0.00..827622.27 rows=17487927 width=295)
-> Append (cost=0.00..827622.27 rows=17487927 width=295)
-> Seq Scan on logs (cost=0.00..826232.78 rows=17451978 width=165)
-> Seq Scan on logs_150 logs (cost=0.00..199.04 rows=6104 width=144)
-> Seq Scan on logs_163 logs (cost=0.00..261.79 rows=7079 width=169)
-> Seq Scan on logs_289 logs (cost=0.00..428.93 rows=10693 width=200)
-> Seq Scan on logs_319 logs (cost=0.00..31.92 rows=992 width=129)
-> Seq Scan on logs_238 logs (cost=0.00..28.01 rows=701 width=199)
-> Seq Scan on logs_148 logs (cost=0.00..80.15 rows=2015 width=195)
-> Seq Scan on logs_176 logs (cost=0.00..12.40 rows=240 width=295)
-> Seq Scan on logs_164 logs (cost=0.00..12.40 rows=240 width=295)
-> Seq Scan on logs_316 logs (cost=0.00..12.40 rows=240 width=295)
-> Seq Scan on logs_313 logs (cost=0.00..12.40 rows=240 width=295)
-> Seq Scan on logs_217 logs (cost=0.00..12.40 rows=240 width=295)
-> Seq Scan on logs_167 logs (cost=0.00..57.36 rows=1536 width=170)
-> Seq Scan on logs_287 logs (cost=0.00..12.40 rows=240 width=295)
-> Seq Scan on logs_279 logs (cost=0.00..12.40 rows=240 width=295)
-> Seq Scan on logs_248 logs (cost=0.00..12.40 rows=240 width=295)
-> Seq Scan on logs_280 logs (cost=0.00..12.40 rows=240 width=295)
-> Seq Scan on logs_165 logs (cost=0.00..34.09 rows=909 width=168)
-> Seq Scan on logs_330 logs (cost=0.00..62.46 rows=1746 width=160)
-> Seq Scan on logs_149 logs (cost=0.00..12.40 rows=240 width=295)
-> Seq Scan on logs_157 logs (cost=0.00..12.40 rows=240 width=295)
-> Seq Scan on logs_272 logs (cost=0.00..32.14 rows=814 width=183)
-> Seq Scan on logs_311 logs (cost=0.00..12.40 rows=240 width=295)
-> Seq Scan on logs_309 logs (cost=0.00..12.40 rows=240 width=295)
-> Seq Scan on logs_318 logs (cost=0.00..12.40 rows=240 width=295)
* Re: partitioning
2005-12-13 08:20 partitioning Marc Cousin <mcousin@sigma.fr>
@ 2005-12-13 11:40 ` Pandurangan R S <pandurangan.r.s@gmail.com>
2005-12-13 11:50 ` Re: partitioning Pandurangan R S <pandurangan.r.s@gmail.com>
0 siblings, 1 reply; 33+ messages in thread
From: Pandurangan R S @ 2005-12-13 11:40 UTC (permalink / raw)
To: Marc Cousin <mcousin@sigma.fr>; +Cc: pgsql-performance
Did you set constraint_exclusion = true in postgresql.conf file?
On 12/13/05, Marc Cousin <mcousin@sigma.fr> wrote:
> Hi,
>
> I've been working on trying to partition a big table (I've never partitioned a
> table in any other database till now).
> Everything went ok, except one query that didn't work afterwards.
>
> I've put the partition description, indexes, etc ..., and the explain plan
> attached.
>
> The query is extremely fast without partition (index scan backards on the
> primary key)
>
> The query is : "select * from logs order by id desc limit 100;"
> id is the primary key.
>
> It is indexed on all partitions.
>
> But the explain plan does full table scan on all partitions.
>
> While I think I understand why it is doing this plan right now, is there
> something that could be done to optimize this case ? Or put a warning in the
> docs about this kind of behaviour. I guess normally someone would partition
> to get faster queries :)
>
> Anyway, I thought I should mention this, as it has been quite a surprise.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
>
>
>
--
Regards
Pandu
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: partitioning
2005-12-13 08:20 partitioning Marc Cousin <mcousin@sigma.fr>
2005-12-13 11:40 ` Re: partitioning Pandurangan R S <pandurangan.r.s@gmail.com>
@ 2005-12-13 11:50 ` Pandurangan R S <pandurangan.r.s@gmail.com>
2005-12-13 13:11 ` Re: partitioning Marc Cousin <mcousin@sigma.fr>
0 siblings, 1 reply; 33+ messages in thread
From: Pandurangan R S @ 2005-12-13 11:50 UTC (permalink / raw)
To: Marc Cousin <mcousin@sigma.fr>; +Cc: pgsql-performance
I just saw that there is no where clause in the query, that you had
fed to explain plan.
you need to include a where clause based on id_machine column to see the effect.
On 12/13/05, Pandurangan R S <pandurangan.r.s@gmail.com> wrote:
> Did you set constraint_exclusion = true in postgresql.conf file?
>
> On 12/13/05, Marc Cousin <mcousin@sigma.fr> wrote:
> > Hi,
> >
> > I've been working on trying to partition a big table (I've never partitioned a
> > table in any other database till now).
> > Everything went ok, except one query that didn't work afterwards.
> >
> > I've put the partition description, indexes, etc ..., and the explain plan
> > attached.
> >
> > The query is extremely fast without partition (index scan backards on the
> > primary key)
> >
> > The query is : "select * from logs order by id desc limit 100;"
> > id is the primary key.
> >
> > It is indexed on all partitions.
> >
> > But the explain plan does full table scan on all partitions.
> >
> > While I think I understand why it is doing this plan right now, is there
> > something that could be done to optimize this case ? Or put a warning in the
> > docs about this kind of behaviour. I guess normally someone would partition
> > to get faster queries :)
> >
> > Anyway, I thought I should mention this, as it has been quite a surprise.
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly
> >
> >
> >
> >
>
>
> --
> Regards
> Pandu
>
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: partitioning
2005-12-13 08:20 partitioning Marc Cousin <mcousin@sigma.fr>
2005-12-13 11:40 ` Re: partitioning Pandurangan R S <pandurangan.r.s@gmail.com>
2005-12-13 11:50 ` Re: partitioning Pandurangan R S <pandurangan.r.s@gmail.com>
@ 2005-12-13 13:11 ` Marc Cousin <mcousin@sigma.fr>
0 siblings, 0 replies; 33+ messages in thread
From: Marc Cousin @ 2005-12-13 13:11 UTC (permalink / raw)
To: pgsql-performance
Yes, that's how I solved it... and I totally agree that it's hard for the
planner to guess what to do on the partitions. But maybe there should be
something in the docs explaining the limitations ...
I'm only asking for the biggest 100 ids from the table, so I thought maybe the
planner would take the 100 biggest from all partitions or something like that
and return me the 100 biggest from those results. It didn't and that's quite
logical.
What I meant is that I understand why the planner chooses this plan, but maybe
it should be written somewhere in the docs that some plans will be worse
after partitionning.
Le Mardi 13 Décembre 2005 12:50, vous avez écrit :
> I just saw that there is no where clause in the query, that you had
> fed to explain plan.
> you need to include a where clause based on id_machine column to see the
> effect.
>
> On 12/13/05, Pandurangan R S <pandurangan.r.s@gmail.com> wrote:
> > Did you set constraint_exclusion = true in postgresql.conf file?
> >
> > On 12/13/05, Marc Cousin <mcousin@sigma.fr> wrote:
> > > Hi,
> > >
> > > I've been working on trying to partition a big table (I've never
> > > partitioned a table in any other database till now).
> > > Everything went ok, except one query that didn't work afterwards.
> > >
> > > I've put the partition description, indexes, etc ..., and the explain
> > > plan attached.
> > >
> > > The query is extremely fast without partition (index scan backards on
> > > the primary key)
> > >
> > > The query is : "select * from logs order by id desc limit 100;"
> > > id is the primary key.
> > >
> > > It is indexed on all partitions.
> > >
> > > But the explain plan does full table scan on all partitions.
> > >
> > > While I think I understand why it is doing this plan right now, is
> > > there something that could be done to optimize this case ? Or put a
> > > warning in the docs about this kind of behaviour. I guess normally
> > > someone would partition to get faster queries :)
> > >
> > > Anyway, I thought I should mention this, as it has been quite a
> > > surprise.
> > >
> > >
> > >
> > > ---------------------------(end of
> > > broadcast)--------------------------- TIP 1: if posting/reading through
> > > Usenet, please send an appropriate subscribe-nomail command to
> > > majordomo@postgresql.org so that your message can get through to the
> > > mailing list cleanly
> >
> > --
> > Regards
> > Pandu
^ permalink raw reply [nested|flat] 33+ messages in thread
* partitioning
@ 2006-03-19 12:31 Antoine <melser.anton@gmail.com>
2006-03-21 09:59 ` Re: partitioning Jim C. Nasby <jnasby@pervasive.com>
0 siblings, 1 reply; 33+ messages in thread
From: Antoine @ 2006-03-19 12:31 UTC (permalink / raw)
To: pgsql-performance
Hi,
Is there any work on the cards for implementing other partitioning
strategies? I see mysql 5.1 will have support for hashes and stuff but
didn't see anything in the todos for postgres.
Cheers
Antoine
--
This is where I should put some witty comment.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: partitioning
2006-03-19 12:31 partitioning Antoine <melser.anton@gmail.com>
@ 2006-03-21 09:59 ` Jim C. Nasby <jnasby@pervasive.com>
0 siblings, 0 replies; 33+ messages in thread
From: Jim C. Nasby @ 2006-03-21 09:59 UTC (permalink / raw)
To: Antoine <melser.anton@gmail.com>; +Cc: pgsql-performance
On Sun, Mar 19, 2006 at 01:31:42PM +0100, Antoine wrote:
> Hi,
> Is there any work on the cards for implementing other partitioning
> strategies? I see mysql 5.1 will have support for hashes and stuff but
> didn't see anything in the todos for postgres.
You'd have to provide a pretty convincing argument for providing hash
partitioning I think. I can't really think of any real-world scenarios
where it's better than other forms.
In any case, the next logical step on the partitioning front is to add
some 'syntactic sugar' to make it easier for people to work with
partitions. I seem to remember some discussion about that, but I don't
recall where it lead to.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
^ permalink raw reply [nested|flat] 33+ messages in thread
* Partitioning
@ 2006-12-26 18:36 Kevin Hunter <hunteke@earlham.edu>
2006-12-26 19:55 ` Re: Partitioning Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 33+ messages in thread
From: Kevin Hunter @ 2006-12-26 18:36 UTC (permalink / raw)
To: PostrgreSQL Novice List <pgsql-novice@postgresql.org>
Hi All,
A friend has asked me about creating a unique table for individual users
that sign up for his site. (In essence, each user who signs up would
essentially get a set of CREATE TABLE {users,friends,movies,eats}_<id> (
... ); statements executed, the idea being to reduce the number of rows
that the DB needs to search or index/update in regards to a particular
user id.) The just seems ludicrous to me, because the database still
needs to find those tables from its internal structure, not to mention
that it just seems silly to me from a design perspective. Something
about unable to optimize any queries because not only is the WHERE
clause in flux, but so is the FROM clause.
Question: Could someone explain to me why this would be bad idea,
because I can't put into words why it is. Or is it a good idea?
(Towards learning, I'm looking for a technical, Postgres oriented
answer, as well as the more general answer.)
Since he's worried about performance, methinks a better idea would be to
use the partitioning support of Postgres. Is this a good hunch?
(Side question: When did Postgres get partitioning support? I see it
referenced in the 8.1 documentation but not before.)
Thanks,
Kevin
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2006-12-26 18:36 Partitioning Kevin Hunter <hunteke@earlham.edu>
@ 2006-12-26 19:55 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-12-26 22:29 ` Re: [NOVICE] Partitioning Kevin Hunter <hunteke@earlham.edu>
0 siblings, 1 reply; 33+ messages in thread
From: Tom Lane @ 2006-12-26 19:55 UTC (permalink / raw)
To: Kevin Hunter <hunteke@earlham.edu>; +Cc: PostrgreSQL Novice List <pgsql-novice@postgresql.org>
Kevin Hunter <hunteke@earlham.edu> writes:
> A friend has asked me about creating a unique table for individual users
> that sign up for his site. (In essence, each user who signs up would
> essentially get a set of CREATE TABLE {users,friends,movies,eats}_<id> (
> ... ); statements executed, the idea being to reduce the number of rows
> that the DB needs to search or index/update in regards to a particular
> user id.) The just seems ludicrous to me, because the database still
> needs to find those tables from its internal structure, not to mention
> that it just seems silly to me from a design perspective. Something
> about unable to optimize any queries because not only is the WHERE
> clause in flux, but so is the FROM clause.
> Question: Could someone explain to me why this would be bad idea,
> because I can't put into words why it is.
I thought you did a fine job right there ;-). In essence this would be
replacing one level of indexing with two, which is unlikely to be a win.
If you have exactly M rows in each of N tables then theoretically your
lookup costs would be about O(log(N) + log(M)), which is nominally the
same as O(log(M*N)) which is the cost to index into one big table --- so
at best you break even, and that's ignoring the fact that index search
has a nonzero startup cost that'll be paid twice in the first case.
But the real problem is that if the N tables contain different numbers
of rows then you have an unevenly filled search tree, which is a net
loss.
Most DBMSes aren't really designed to scale to many thousands of tables
anyway. In Postgres this would result in many thousands of files in
the same database directory, which probably creates some filesystem
lookup inefficiencies in addition to whatever might be inherent to
Postgres.
Partitioning is indeed something that is commonly done, but on a very
coarse grain --- you might have a dozen or two active partitions, not
thousands. The point of partitioning is either to spread a huge table
across multiple filesystems (and how many filesystems have you got?)
or else to make predictable removals of segments of the data cheap (for
instance, dropping the oldest month's worth of data once a month, in a
table where you only keep the last year or so's worth of data on-line).
I can't see doing it on a per-user basis.
regards, tom lane
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: [NOVICE] Partitioning
2006-12-26 18:36 Partitioning Kevin Hunter <hunteke@earlham.edu>
2006-12-26 19:55 ` Re: Partitioning Tom Lane <tgl@sss.pgh.pa.us>
@ 2006-12-26 22:29 ` Kevin Hunter <hunteke@earlham.edu>
2006-12-27 04:37 ` Re: [NOVICE] Partitioning Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 33+ messages in thread
From: Kevin Hunter @ 2006-12-26 22:29 UTC (permalink / raw)
To: pgsql-performance
On 26 Dec 2006 at 2:55p -0500, Tom Lane wrote:
> Kevin Hunter <hunteke@earlham.edu> writes:
>> A friend has asked me about creating a unique table for individual users
>> that sign up for his site. (In essence, each user who signs up would
>> essentially get a set of CREATE TABLE {users,friends,movies,eats}_<id> (
>> ... ); statements executed, the idea being to reduce the number of rows
>> that the DB needs to search or index/update in regards to a particular
>> user id.) The just seems ludicrous to me, because the database still
>> needs to find those tables from its internal structure, not to mention
>> that it just seems silly to me from a design perspective. Something
>> about unable to optimize any queries because not only is the WHERE
>> clause in flux, but so is the FROM clause.
>
>> Question: Could someone explain to me why this would be bad idea,
>> because I can't put into words why it is.
>
> I thought you did a fine job right there ;-). In essence this would be
> replacing one level of indexing with two, which is unlikely to be a win.
> If you have exactly M rows in each of N tables then theoretically your
> lookup costs would be about O(log(N) + log(M)), which is nominally the
> same as O(log(M*N)) which is the cost to index into one big table --- so
> at best you break even, and that's ignoring the fact that index search
> has a nonzero startup cost that'll be paid twice in the first case.
> But the real problem is that if the N tables contain different numbers
> of rows then you have an unevenly filled search tree, which is a net
> loss.
Hurm. If I remember my Algorithms/Data Structures course, that implies
that table lookup is implemented with a B-Tree . . . right? Since at
SQL preparation time the tables in the query are known, why couldn't you
use a hash lookup? In the above case, that would make it effectively
O(1 + log(M)) or O(log(M)). Granted, it's /still/ a bad idea because of
the next paragraph . . .
> Most DBMSes aren't really designed to scale to many thousands of tables
> anyway. In Postgres this would result in many thousands of files in
> the same database directory, which probably creates some filesystem
> lookup inefficiencies in addition to whatever might be inherent to
> Postgres.
So, still a bad idea, but I couldn't immediately think of why. Thank you.
> Partitioning is indeed something that is commonly done, but on a very
> coarse grain --- you might have a dozen or two active partitions, not
> thousands. The point of partitioning is either to spread a huge table
> across multiple filesystems (and how many filesystems have you got?)
> or else to make predictable removals of segments of the data cheap (for
> instance, dropping the oldest month's worth of data once a month, in a
> table where you only keep the last year or so's worth of data on-line).
Ah! I was missing where to hang/put partitioning in my head. Thank you
again!
> I can't see doing it on a per-user basis.
Perhaps not on a per-user basis, but he could certainly improve access
times by partitioning even coursely. I'll point him in that direction
Are there other, perhaps better ways to improve the access times? (Now
I'm curious just for my sake.) The best that I keep reading is just to
do as much in parallel as possible (i.e. multiple systems) and to use
Postgres ( :) ).
Thanks,
Kevin
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: [NOVICE] Partitioning
2006-12-26 18:36 Partitioning Kevin Hunter <hunteke@earlham.edu>
2006-12-26 19:55 ` Re: Partitioning Tom Lane <tgl@sss.pgh.pa.us>
2006-12-26 22:29 ` Re: [NOVICE] Partitioning Kevin Hunter <hunteke@earlham.edu>
@ 2006-12-27 04:37 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 33+ messages in thread
From: Tom Lane @ 2006-12-27 04:37 UTC (permalink / raw)
To: Kevin Hunter <hunteke@earlham.edu>; +Cc: pgsql-performance
Kevin Hunter <hunteke@earlham.edu> writes:
> On 26 Dec 2006 at 2:55p -0500, Tom Lane wrote:
>> I thought you did a fine job right there ;-). In essence this would be
>> replacing one level of indexing with two, which is unlikely to be a win.
>> If you have exactly M rows in each of N tables then theoretically your
>> lookup costs would be about O(log(N) + log(M)), which is nominally the
>> same as O(log(M*N)) which is the cost to index into one big table --- so
> Hurm. If I remember my Algorithms/Data Structures course, that implies
> that table lookup is implemented with a B-Tree . . . right?
b-tree or something else with log-N behavior. I think it can be proved
that every search method is at best log-N once N gets large enough, but
of course that might be for N far beyond any practical values.
> Since at SQL preparation time the tables in the query are known, why
> couldn't you use a hash lookup?
The hash index implementation currently available in Postgres hasn't
ever been proven to beat our b-tree implementation, on any dimension.
This might be a matter of how much effort has been thrown at it, or
maybe there's some fundamental problem; but anyway you won't find a
lot of enthusiasm around here for moving the system-catalog indexes
to hashing...
>> I can't see doing it on a per-user basis.
> Perhaps not on a per-user basis, but he could certainly improve access
> times by partitioning even coursely. I'll point him in that direction
> Are there other, perhaps better ways to improve the access times?
Actually, I forgot to mention an interesting talk I heard last month,
wherein Casey Duncan explained how pandora.com scales across an
unreasonable number of users whose queries are mostly-but-not-always
localized. Essentially they partition their tables on the basis of
a hash of the user ID, where there are as many hash result values
as they have servers. The point still remains though that there
are far fewer partitions than users. I think what you want to take
away is that you choose the number of partitions based on physical
implementation numbers ("how many filesystems do we have today")
and not on logical numbers like "how many users do we have today".
regards, tom lane
^ permalink raw reply [nested|flat] 33+ messages in thread
* Partitioning
@ 2007-01-05 11:02 Arnau <arnaulist@andromeiberica.com>
0 siblings, 0 replies; 33+ messages in thread
From: Arnau @ 2007-01-05 11:02 UTC (permalink / raw)
To: pgsql-performance
Hi all,
I'm not sure if this question fits in the topic of this list.
I'm interested in partitioning and it's the first time I'd use it.
There is an issue I don't know how you handle it. Lets say I'm
interested in store monthly based statistical data like the example of
http://www.postgresql.org/docs/8.2/static/ddl-partitioning.html. What I
don't like of this approach is that the monthly tables, rules... must be
created "manually" or at least I haven't found any other option.
My question is how do you manage this? do you have a cron task that
creates automatically these monthly elements (tables, rules, ... ) or
there is another approach that doesn't require external things like cron
only PostgreSQL.
--
Arnau
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
@ 2007-01-05 11:47 Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
2007-01-10 20:20 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
0 siblings, 1 reply; 33+ messages in thread
From: Mikael Carneholm @ 2007-01-05 11:47 UTC (permalink / raw)
To: arnaulist@andromeiberica.com; pgsql-performance
Take a look at the set of partitioning functions I wrote shortly after
the 8.1 release:
http://www.studenter.hb.se/~arch/files/part_functions.sql
You could probably work something out using those functions (as-is, or
as inspiration) together with pgAgent
(http://www.pgadmin.org/docs/1.4/pgagent.html)
/Mikael
> -----Original Message-----
> From: pgsql-performance-owner@postgresql.org
[mailto:pgsql-performance-
> owner@postgresql.org] On Behalf Of Arnau
> Sent: den 5 januari 2007 12:02
> To: pgsql-performance@postgresql.org
> Subject: [PERFORM] Partitioning
>
> Hi all,
>
> I'm not sure if this question fits in the topic of this list.
>
> I'm interested in partitioning and it's the first time I'd use it.
> There is an issue I don't know how you handle it. Lets say I'm
> interested in store monthly based statistical data like the example of
> http://www.postgresql.org/docs/8.2/static/ddl-partitioning.html. What
I
> don't like of this approach is that the monthly tables, rules... must
be
> created "manually" or at least I haven't found any other option.
>
> My question is how do you manage this? do you have a cron task that
> creates automatically these monthly elements (tables, rules, ... ) or
> there is another approach that doesn't require external things like
cron
> only PostgreSQL.
> --
> Arnau
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2007-01-05 11:47 Re: Partitioning Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
@ 2007-01-10 20:20 ` Jim C. Nasby <jim@nasby.net>
2007-01-10 20:28 ` Re: Partitioning Jeremy Haile <jhaile@fastmail.fm>
2007-01-10 20:30 ` Re: Partitioning Erik Jones <erik@myemma.com>
0 siblings, 2 replies; 33+ messages in thread
From: Jim C. Nasby @ 2007-01-10 20:20 UTC (permalink / raw)
To: Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>; +Cc: arnaulist@andromeiberica.com; pgsql-performance
BTW, someone coming up with a set of functions to handle partitioning
for the general 'partition by time' case would make a GREAT project on
pgFoundry.
On Fri, Jan 05, 2007 at 12:47:08PM +0100, Mikael Carneholm wrote:
> Take a look at the set of partitioning functions I wrote shortly after
> the 8.1 release:
>
> http://www.studenter.hb.se/~arch/files/part_functions.sql
>
> You could probably work something out using those functions (as-is, or
> as inspiration) together with pgAgent
> (http://www.pgadmin.org/docs/1.4/pgagent.html)
>
> /Mikael
>
> > -----Original Message-----
> > From: pgsql-performance-owner@postgresql.org
> [mailto:pgsql-performance-
> > owner@postgresql.org] On Behalf Of Arnau
> > Sent: den 5 januari 2007 12:02
> > To: pgsql-performance@postgresql.org
> > Subject: [PERFORM] Partitioning
> >
> > Hi all,
> >
> > I'm not sure if this question fits in the topic of this list.
> >
> > I'm interested in partitioning and it's the first time I'd use it.
> > There is an issue I don't know how you handle it. Lets say I'm
> > interested in store monthly based statistical data like the example of
> > http://www.postgresql.org/docs/8.2/static/ddl-partitioning.html. What
> I
> > don't like of this approach is that the monthly tables, rules... must
> be
> > created "manually" or at least I haven't found any other option.
> >
> > My question is how do you manage this? do you have a cron task that
> > creates automatically these monthly elements (tables, rules, ... ) or
> > there is another approach that doesn't require external things like
> cron
> > only PostgreSQL.
> > --
> > Arnau
> >
> > ---------------------------(end of
> broadcast)---------------------------
> > TIP 5: don't forget to increase your free space map settings
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2007-01-05 11:47 Re: Partitioning Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
2007-01-10 20:20 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
@ 2007-01-10 20:28 ` Jeremy Haile <jhaile@fastmail.fm>
2007-01-10 21:09 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
1 sibling, 1 reply; 33+ messages in thread
From: Jeremy Haile @ 2007-01-10 20:28 UTC (permalink / raw)
To: pgsql-performance
I really wish that PostgreSQL supported a "nice" partitioning syntax
like MySQL has.
Here is an example:
CREATE TABLE tr (id INT, name VARCHAR(50), purchased DATE)
PARTITION BY RANGE( YEAR(purchased) ) (
PARTITION p0 VALUES LESS THAN (1990),
PARTITION p1 VALUES LESS THAN (1995),
PARTITION p2 VALUES LESS THAN (2000),
PARTITION p3 VALUES LESS THAN (2005)
);
And to drop a partition:
ALTER TABLE tr DROP PARTITION p2;
This seems so much more intuitive and simpler than what is required to
set it up in PostgreSQL. Does PostgreSQL's approach to table
partitioning have any advantage over MySQL? Is a "nicer" syntax planned
for Postgres?
On Wed, 10 Jan 2007 14:20:06 -0600, "Jim C. Nasby" <jim@nasby.net> said:
> BTW, someone coming up with a set of functions to handle partitioning
> for the general 'partition by time' case would make a GREAT project on
> pgFoundry.
>
> On Fri, Jan 05, 2007 at 12:47:08PM +0100, Mikael Carneholm wrote:
> > Take a look at the set of partitioning functions I wrote shortly after
> > the 8.1 release:
> >
> > http://www.studenter.hb.se/~arch/files/part_functions.sql
> >
> > You could probably work something out using those functions (as-is, or
> > as inspiration) together with pgAgent
> > (http://www.pgadmin.org/docs/1.4/pgagent.html)
> >
> > /Mikael
> >
> > > -----Original Message-----
> > > From: pgsql-performance-owner@postgresql.org
> > [mailto:pgsql-performance-
> > > owner@postgresql.org] On Behalf Of Arnau
> > > Sent: den 5 januari 2007 12:02
> > > To: pgsql-performance@postgresql.org
> > > Subject: [PERFORM] Partitioning
> > >
> > > Hi all,
> > >
> > > I'm not sure if this question fits in the topic of this list.
> > >
> > > I'm interested in partitioning and it's the first time I'd use it.
> > > There is an issue I don't know how you handle it. Lets say I'm
> > > interested in store monthly based statistical data like the example of
> > > http://www.postgresql.org/docs/8.2/static/ddl-partitioning.html. What
> > I
> > > don't like of this approach is that the monthly tables, rules... must
> > be
> > > created "manually" or at least I haven't found any other option.
> > >
> > > My question is how do you manage this? do you have a cron task that
> > > creates automatically these monthly elements (tables, rules, ... ) or
> > > there is another approach that doesn't require external things like
> > cron
> > > only PostgreSQL.
> > > --
> > > Arnau
> > >
> > > ---------------------------(end of
> > broadcast)---------------------------
> > > TIP 5: don't forget to increase your free space map settings
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 9: In versions below 8.0, the planner will ignore your desire to
> > choose an index scan if your joining column's datatypes do not
> > match
> >
>
> --
> Jim Nasby jim@nasby.net
> EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2007-01-05 11:47 Re: Partitioning Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
2007-01-10 20:20 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
2007-01-10 20:28 ` Re: Partitioning Jeremy Haile <jhaile@fastmail.fm>
@ 2007-01-10 21:09 ` Jim C. Nasby <jim@nasby.net>
2007-01-10 21:15 ` Re: Partitioning Jeremy Haile <jhaile@fastmail.fm>
2007-01-10 21:30 ` Re: Partitioning Scott Marlowe <smarlowe@g2switchworks.com>
0 siblings, 2 replies; 33+ messages in thread
From: Jim C. Nasby @ 2007-01-10 21:09 UTC (permalink / raw)
To: Jeremy Haile <jhaile@fastmail.fm>; +Cc: pgsql-performance
On Wed, Jan 10, 2007 at 03:28:00PM -0500, Jeremy Haile wrote:
> This seems so much more intuitive and simpler than what is required to
> set it up in PostgreSQL. Does PostgreSQL's approach to table
> partitioning have any advantage over MySQL? Is a "nicer" syntax planned
> for Postgres?
The focus was to get the base functionality working, and working
correctly. Another consideration is that there's multiple ways to
accomplish the partitioning; exposing the basic functionality without
enforcing a given interface provides more flexibility (ie: it appears
that you can't do list partitioning with MySQL, while you can with
PostgreSQL).
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2007-01-05 11:47 Re: Partitioning Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
2007-01-10 20:20 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
2007-01-10 20:28 ` Re: Partitioning Jeremy Haile <jhaile@fastmail.fm>
2007-01-10 21:09 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
@ 2007-01-10 21:15 ` Jeremy Haile <jhaile@fastmail.fm>
2007-01-10 21:51 ` Re: Partitioning Scott Marlowe <smarlowe@g2switchworks.com>
1 sibling, 1 reply; 33+ messages in thread
From: Jeremy Haile @ 2007-01-10 21:15 UTC (permalink / raw)
To: Jim C. Nasby <jim@nasby.net>; +Cc: pgsql-performance
You can do list partitioning in MySQL:
http://dev.mysql.com/doc/refman/5.1/en/partitioning-list.html
My comment was not meant as a criticism of PostgreSQL's current state -
I'm glad that it has partitioning. I'm simply wondering if there are
any plans of adopting a more user-friendly syntax in the future similar
to MySQL partitioning support. Having first-class citizen support of
partitions would also allow some nice administrative GUIs and views to
be built for managing them.
Jeremy Haile
On Wed, 10 Jan 2007 15:09:31 -0600, "Jim C. Nasby" <jim@nasby.net> said:
> On Wed, Jan 10, 2007 at 03:28:00PM -0500, Jeremy Haile wrote:
> > This seems so much more intuitive and simpler than what is required to
> > set it up in PostgreSQL. Does PostgreSQL's approach to table
> > partitioning have any advantage over MySQL? Is a "nicer" syntax planned
> > for Postgres?
>
> The focus was to get the base functionality working, and working
> correctly. Another consideration is that there's multiple ways to
> accomplish the partitioning; exposing the basic functionality without
> enforcing a given interface provides more flexibility (ie: it appears
> that you can't do list partitioning with MySQL, while you can with
> PostgreSQL).
> --
> Jim Nasby jim@nasby.net
> EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2007-01-05 11:47 Re: Partitioning Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
2007-01-10 20:20 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
2007-01-10 20:28 ` Re: Partitioning Jeremy Haile <jhaile@fastmail.fm>
2007-01-10 21:09 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
2007-01-10 21:15 ` Re: Partitioning Jeremy Haile <jhaile@fastmail.fm>
@ 2007-01-10 21:51 ` Scott Marlowe <smarlowe@g2switchworks.com>
0 siblings, 0 replies; 33+ messages in thread
From: Scott Marlowe @ 2007-01-10 21:51 UTC (permalink / raw)
To: Jeremy Haile <jhaile@fastmail.fm>; +Cc: Jim C. Nasby <jim@nasby.net>; pgsql-performance
On Wed, 2007-01-10 at 15:15, Jeremy Haile wrote:
> You can do list partitioning in MySQL:
> http://dev.mysql.com/doc/refman/5.1/en/partitioning-list.html
>
> My comment was not meant as a criticism of PostgreSQL's current state -
> I'm glad that it has partitioning. I'm simply wondering if there are
> any plans of adopting a more user-friendly syntax in the future similar
> to MySQL partitioning support. Having first-class citizen support of
> partitions would also allow some nice administrative GUIs and views to
> be built for managing them.
I don't think anyone took it as a negative criticism. Jim and I were
both more pointing out that the development process of the two projects
is somewhat different.
In MySQL a small group that doesn't necessarily interact with a large
user community sets out to implement a feature in a given time line with
a given set of requirements and they tend to ignore what they see as
esoteric requirements.
In PostgreSQL a large development community that communicates fairly
well with it's large user community put somewhat of the onus of proving
the need and doing the initial proof of concept on those who say they
need a feature, often working in a method where the chief hackers lend a
hand to someone who wants the feature so they can get a proof of concept
up and running. And example would be the auditing / time travel in the
contrib/spi project. After several iterations, and given the chance to
learn from the mistakes of the previous incarnations, something often
rises out of that to produce the feature needed.
Generally speaking the postgresql method takes longer, making life
harder today, but produces cleaner more easily maintained solutions,
making life easier in the future. Meanwhile the mysql method works
faster, making life easier today, but makes compromises that might make
life harder in the future.
Something that embodies that difference is the table handler philosophy
of both databases. PostgreSQL has the abstraction to have more than one
table handler, but in practice has exactly one table handler. MySQL has
the ability to have many table handlers, and in fact uses many of them.
With PostgreSQL this means that things like the query parsing /
execution and the table handler are tightly coupled. This results in
things like transactable DDL. Sometimes this results in suggestions
being dismissed out of hand because they would have unintended
consequences.
In MySQL, because of the multiple table handlers, many compromises on
the query parsing have to be made. The most common one being that you
can define constraints / foreign keys in a column item, and they will
simply be ignored with no error or notice. The fk constraints have to
go at the end of the column list to be parsed and executed.
So, partitioning, being something that will touch a lot of parts of the
database, isn't gonna just show up one afternoon in pgsql. It will
likely take a few people making proof of concept versions before a
consensus is reached and someone who has the ability codes it up.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2007-01-05 11:47 Re: Partitioning Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
2007-01-10 20:20 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
2007-01-10 20:28 ` Re: Partitioning Jeremy Haile <jhaile@fastmail.fm>
2007-01-10 21:09 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
@ 2007-01-10 21:30 ` Scott Marlowe <smarlowe@g2switchworks.com>
2007-01-11 12:51 ` Re: Partitioning Bernd Helmle <mailings@oopsware.de>
1 sibling, 1 reply; 33+ messages in thread
From: Scott Marlowe @ 2007-01-10 21:30 UTC (permalink / raw)
To: Jim C. Nasby <jim@nasby.net>; +Cc: Jeremy Haile <jhaile@fastmail.fm>; pgsql-performance
On Wed, 2007-01-10 at 15:09, Jim C. Nasby wrote:
> On Wed, Jan 10, 2007 at 03:28:00PM -0500, Jeremy Haile wrote:
> > This seems so much more intuitive and simpler than what is required to
> > set it up in PostgreSQL. Does PostgreSQL's approach to table
> > partitioning have any advantage over MySQL? Is a "nicer" syntax planned
> > for Postgres?
>
> The focus was to get the base functionality working, and working
> correctly. Another consideration is that there's multiple ways to
> accomplish the partitioning; exposing the basic functionality without
> enforcing a given interface provides more flexibility (ie: it appears
> that you can't do list partitioning with MySQL, while you can with
> PostgreSQL).
And I don't think the mysql partition supports tablespaces either.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2007-01-05 11:47 Re: Partitioning Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
2007-01-10 20:20 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
2007-01-10 20:28 ` Re: Partitioning Jeremy Haile <jhaile@fastmail.fm>
2007-01-10 21:09 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
2007-01-10 21:30 ` Re: Partitioning Scott Marlowe <smarlowe@g2switchworks.com>
@ 2007-01-11 12:51 ` Bernd Helmle <mailings@oopsware.de>
2007-01-11 14:18 ` Re: Partitioning Adam Rich <adam.r@sbcglobal.net>
0 siblings, 1 reply; 33+ messages in thread
From: Bernd Helmle @ 2007-01-11 12:51 UTC (permalink / raw)
To: Scott Marlowe <smarlowe@g2switchworks.com>; +Cc: Jim C. Nasby <jim@nasby.net>; Jeremy Haile <jhaile@fastmail.fm>; pgsql-performance
On Wed, 10 Jan 2007 15:30:16 -0600, Scott Marlowe <smarlowe@g2switchworks.com> wrote:
[...]
>
> And I don't think the mysql partition supports tablespaces either.
>
MySQL supports distributing partitions over multiple disks via the SUBPARTITION clause [1].
I leave it to you, wether their syntax is cleaner, more powerful or easier or ....;)
Bernd
[1] http://dev.mysql.com/doc/refman/5.1/en/partitioning-subpartitions.html
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2007-01-05 11:47 Re: Partitioning Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
2007-01-10 20:20 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
2007-01-10 20:28 ` Re: Partitioning Jeremy Haile <jhaile@fastmail.fm>
2007-01-10 21:09 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
2007-01-10 21:30 ` Re: Partitioning Scott Marlowe <smarlowe@g2switchworks.com>
2007-01-11 12:51 ` Re: Partitioning Bernd Helmle <mailings@oopsware.de>
@ 2007-01-11 14:18 ` Adam Rich <adam.r@sbcglobal.net>
2007-01-11 14:32 ` Re: Partitioning Bernd Helmle <mailings@oopsware.de>
0 siblings, 1 reply; 33+ messages in thread
From: Adam Rich @ 2007-01-11 14:18 UTC (permalink / raw)
To: 'Bernd Helmle' <mailings@oopsware.de>; 'Scott Marlowe' <smarlowe@g2switchworks.com>; +Cc: 'Jim C. Nasby' <jim@nasby.net>; 'Jeremy Haile' <jhaile@fastmail.fm>; pgsql-performance
Each partition can have its own disk, without using subpartitions.
CREATE TABLE th (id INT, name VARCHAR(30), adate DATE)
PARTITION BY LIST(YEAR(adate))
(
PARTITION p1999 VALUES IN (1995, 1999, 2003)
DATA DIRECTORY = '/var/appdata/95/data'
INDEX DIRECTORY = '/var/appdata/95/idx',
PARTITION p2000 VALUES IN (1996, 2000, 2004)
DATA DIRECTORY = '/var/appdata/96/data'
INDEX DIRECTORY = '/var/appdata/96/idx',
PARTITION p2001 VALUES IN (1997, 2001, 2005)
DATA DIRECTORY = '/var/appdata/97/data'
INDEX DIRECTORY = '/var/appdata/97/idx',
PARTITION p2000 VALUES IN (1998, 2002, 2006)
DATA DIRECTORY = '/var/appdata/98/data'
INDEX DIRECTORY = '/var/appdata/98/idx'
);
Subpartitions are just a way to break (parent) partitions up into
smaller pieces. Those of course can be moved to other disks
just like the main partitions.
-----Original Message-----
From: pgsql-performance-owner@postgresql.org
[mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Bernd
Helmle
Sent: Thursday, January 11, 2007 6:51 AM
To: Scott Marlowe
Cc: Jim C. Nasby; Jeremy Haile; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Partitioning
On Wed, 10 Jan 2007 15:30:16 -0600, Scott Marlowe
<smarlowe@g2switchworks.com> wrote:
[...]
>
> And I don't think the mysql partition supports tablespaces either.
>
MySQL supports distributing partitions over multiple disks via the
SUBPARTITION clause [1].
I leave it to you, wether their syntax is cleaner, more powerful or
easier or ....;)
Bernd
[1]
http://dev.mysql.com/doc/refman/5.1/en/partitioning-subpartitions.html
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2007-01-05 11:47 Re: Partitioning Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
2007-01-10 20:20 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
2007-01-10 20:28 ` Re: Partitioning Jeremy Haile <jhaile@fastmail.fm>
2007-01-10 21:09 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
2007-01-10 21:30 ` Re: Partitioning Scott Marlowe <smarlowe@g2switchworks.com>
2007-01-11 12:51 ` Re: Partitioning Bernd Helmle <mailings@oopsware.de>
2007-01-11 14:18 ` Re: Partitioning Adam Rich <adam.r@sbcglobal.net>
@ 2007-01-11 14:32 ` Bernd Helmle <mailings@oopsware.de>
0 siblings, 0 replies; 33+ messages in thread
From: Bernd Helmle @ 2007-01-11 14:32 UTC (permalink / raw)
To: Adam Rich <adam.r@sbcglobal.net>; +Cc: Scott Marlowe <smarlowe@g2switchworks.com>; Jim C. Nasby <jim@nasby.net>; Jeremy Haile <jhaile@fastmail.fm>; pgsql-performance
On Thu, 11 Jan 2007 08:18:39 -0600, "Adam Rich" <adam.r@sbcglobal.net> wrote:
>
> Subpartitions are just a way to break (parent) partitions up into
> smaller pieces. Those of course can be moved to other disks
> just like the main partitions.
Ah, didn't know that (i just wondered why i need a subpartition to
change the location of a partition).
Thanks for your clarification...
Bernd
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2007-01-05 11:47 Re: Partitioning Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
2007-01-10 20:20 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
@ 2007-01-10 20:30 ` Erik Jones <erik@myemma.com>
2007-01-11 12:59 ` Re: Partitioning Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
1 sibling, 1 reply; 33+ messages in thread
From: Erik Jones @ 2007-01-10 20:30 UTC (permalink / raw)
To: Jim C. Nasby <jim@nasby.net>; +Cc: Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>; arnaulist@andromeiberica.com; pgsql-performance
On Fri, Jan 05, 2007 at 12:47:08PM +0100, Mikael Carneholm wrote:
>> Take a look at the set of partitioning functions I wrote shortly after
>> the 8.1 release:
>>
>> http://www.studenter.hb.se/~arch/files/part_functions.sql
>>
>> You could probably work something out using those functions (as-is, or
>> as inspiration) together with pgAgent
>> (http://www.pgadmin.org/docs/1.4/pgagent.html)
>>
>> /Mikael
>>
Those are some great functions.
--
erik jones <erik@myemma.com>
software development
emma(r)
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2007-01-05 11:47 Re: Partitioning Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
2007-01-10 20:20 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
2007-01-10 20:30 ` Re: Partitioning Erik Jones <erik@myemma.com>
@ 2007-01-11 12:59 ` Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
2007-01-11 14:02 ` Re: Partitioning Jeremy Haile <jhaile@fastmail.fm>
0 siblings, 1 reply; 33+ messages in thread
From: Mikael Carneholm @ 2007-01-11 12:59 UTC (permalink / raw)
To: Erik Jones <erik@myemma.com>; Jim C. Nasby <jim@nasby.net>; +Cc: arnaulist@andromeiberica.com; pgsql-performance
> On Fri, Jan 05, 2007 at 12:47:08PM +0100, Mikael Carneholm wrote:
> >> Take a look at the set of partitioning functions I wrote shortly
after
> >> the 8.1 release:
> >>
> >> http://www.studenter.hb.se/~arch/files/part_functions.sql
> >>
> >> You could probably work something out using those functions (as-is,
or
> >> as inspiration) together with pgAgent
> >> (http://www.pgadmin.org/docs/1.4/pgagent.html)
> >>
> >> /Mikael
> >>
> Those are some great functions.
>
Well, they're less than optimal in one aspect: they add one rule per
partition, making them unsuitable for OLTP type applications (actually:
any application where insert performance is crucial). Someone with time
and/or energy could probably fix that, I guess...patches are welcome :)
/Mikael
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2007-01-05 11:47 Re: Partitioning Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
2007-01-10 20:20 ` Re: Partitioning Jim C. Nasby <jim@nasby.net>
2007-01-10 20:30 ` Re: Partitioning Erik Jones <erik@myemma.com>
2007-01-11 12:59 ` Re: Partitioning Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
@ 2007-01-11 14:02 ` Jeremy Haile <jhaile@fastmail.fm>
0 siblings, 0 replies; 33+ messages in thread
From: Jeremy Haile @ 2007-01-11 14:02 UTC (permalink / raw)
To: pgsql-performance
Well - whether or not MySQL's implementation of partitioning has some
deficiency, it sure is a lot easier to set up than PostgreSQL. And I
don't think there is any technical reason that setting up partitioning
on Postgres couldn't be very easy and still be robust.
On Thu, 11 Jan 2007 13:59:20 +0100, "Mikael Carneholm"
<Mikael.Carneholm@WirelessCar.com> said:
> > On Fri, Jan 05, 2007 at 12:47:08PM +0100, Mikael Carneholm wrote:
> > >> Take a look at the set of partitioning functions I wrote shortly
> after
> > >> the 8.1 release:
> > >>
> > >> http://www.studenter.hb.se/~arch/files/part_functions.sql
> > >>
> > >> You could probably work something out using those functions (as-is,
> or
> > >> as inspiration) together with pgAgent
> > >> (http://www.pgadmin.org/docs/1.4/pgagent.html)
> > >>
> > >> /Mikael
> > >>
> > Those are some great functions.
> >
>
> Well, they're less than optimal in one aspect: they add one rule per
> partition, making them unsuitable for OLTP type applications (actually:
> any application where insert performance is crucial). Someone with time
> and/or energy could probably fix that, I guess...patches are welcome :)
>
> /Mikael
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
^ permalink raw reply [nested|flat] 33+ messages in thread
* Partitioning
@ 2007-01-12 11:40 Gauri Kanekar <meetgaurikanekar@gmail.com>
2007-01-30 07:10 ` Re: Partitioning Tomas Vondra <tv@fuzzy.cz>
0 siblings, 1 reply; 33+ messages in thread
From: Gauri Kanekar @ 2007-01-12 11:40 UTC (permalink / raw)
To: pgsql-performance
Can anybody help me out
I just wanted to knw what will be the configuraion settings for partitioning
table so as to make inserts faster on the partitioned tables.
--
Regards
Gauri
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2007-01-12 11:40 Partitioning Gauri Kanekar <meetgaurikanekar@gmail.com>
@ 2007-01-30 07:10 ` Tomas Vondra <tv@fuzzy.cz>
0 siblings, 0 replies; 33+ messages in thread
From: Tomas Vondra @ 2007-01-30 07:10 UTC (permalink / raw)
To: Gauri Kanekar <meetgaurikanekar@gmail.com>; +Cc: pgsql-performance
> Can anybody help me out
>
> I just wanted to knw what will be the configuraion settings for
> partitioning table so as to make inserts faster on the partitioned tables.
Well, that depends. Many questions are important here. Will you insert
into several partitions or only to a single one? Do you need to enforce
some constraint between several partitioned tables?
If you need to insert into several partitions, it can be faster as you
can place them on different drives. If you need to insert only into the
last one (that's usually the case with 'logging' tables) then this
probably won't give a huge performance benefit.
If you need to enforce some kind of constraint between multiple
partitions (possibly from several tables), you'll have to do that
manually using a plpgsql procedure (for example). This is the case with
UNIQUE constraint on a single table, FOREIGN KEY between multimple
partitioned tables, etc. This can mean a serious performance penalty,
esecially when you do mostly insert/update on that table.
This is mostly about application architecture - if you use partitions
incorrectly it's almost impossible to fix that by changing settings in
postgresql.conf.
Tomas
^ permalink raw reply [nested|flat] 33+ messages in thread
* Partitioning
@ 2007-01-30 06:42 Abu Mushayeed <abumushayeed@yahoo.com>
2007-01-30 10:21 ` Re: Partitioning Rigmor Ukuhe <rigmor.ukuhe@finestmedia.ee>
0 siblings, 1 reply; 33+ messages in thread
From: Abu Mushayeed @ 2007-01-30 06:42 UTC (permalink / raw)
To: pgsql-performance
I have partitioned a table based on period (e.g., cdate >= '2007-01-01'::date and cdate<=.2007-03-31':;date).
Now, I am issuing query like cdate >= CURRENT_DATE - 1 and cdate <= CURRENT_DATE, it scans all the partitions. But if I do cdate >= '2007-01-01'::date and cdate<=.2007-03-31'::date it picks the correct partition. Also if I join the cdate field with another table, it does not pick the correct partition.
I would like to know if it is possible to pick the correct partition using the above example.
Thanks
Abu
---------------------------------
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
^ permalink raw reply [nested|flat] 33+ messages in thread
* Re: Partitioning
2007-01-30 06:42 Partitioning Abu Mushayeed <abumushayeed@yahoo.com>
@ 2007-01-30 10:21 ` Rigmor Ukuhe <rigmor.ukuhe@finestmedia.ee>
0 siblings, 0 replies; 33+ messages in thread
From: Rigmor Ukuhe @ 2007-01-30 10:21 UTC (permalink / raw)
To: pgsql-performance
Abu Mushayeed wrote:
> I have partitioned a table based on period (e.g., cdate >=
> '2007-01-01'::date and cdate<=.2007-03-31':;date).
>
> Now, I am issuing query like cdate >= CURRENT_DATE - 1 and cdate <=
> CURRENT_DATE, it scans all the partitions. But if I do cdate >=
> '2007-01-01'::date and cdate<=.2007-03-31'::date it picks the correct
> partition. Also if I join the cdate field with another table, it does
> not pick the correct partition.
>
> I would like to know if it is possible to pick the correct partition
> using the above example.
from http://www.postgresql.org/docs/8.1/interactive/ddl-partitioning.html
..."For the same reason, "stable" functions such as CURRENT_DATE must be
avoided. Joining the partition key to a column of another table will not be
optimized, either."...
Rigmor
>
> Thanks
> Abu
>
> ------------------------------------------------------------------------
> Need Mail bonding?
> Go to the Yahoo! Mail Q&A
> <http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21h...;
> for great tips from Yahoo! Answers
> <http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21h...;
> users. !DSPAM:5,45beea6d287779832115503!
--
Rigmor Ukuhe
Finestmedia Ltd | Software Development Team Manager
gsm : (+372)56467729 | tel : (+372)6558043 | e-mail : rigmor.ukuhe@finestmedia.ee
^ permalink raw reply [nested|flat] 33+ messages in thread
end of thread, other threads:[~2007-01-30 10:21 UTC | newest]
Thread overview: 33+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2004-09-15 21:09 Partitioning J. Andrew Rogers <jrogers@neopolitan.com>
2004-09-16 03:55 ` Greg Stark <gsstark@mit.edu>
2004-09-16 10:58 ` Mike Rylander <mrylander@gmail.com>
2004-09-16 20:39 ` Jim C. Nasby <decibel@decibel.org>
2004-09-16 21:59 ` J. Andrew Rogers <jrogers@neopolitan.com>
2005-12-13 08:20 partitioning Marc Cousin <mcousin@sigma.fr>
2005-12-13 11:40 ` Re: partitioning Pandurangan R S <pandurangan.r.s@gmail.com>
2005-12-13 11:50 ` Re: partitioning Pandurangan R S <pandurangan.r.s@gmail.com>
2005-12-13 13:11 ` Re: partitioning Marc Cousin <mcousin@sigma.fr>
2006-03-19 12:31 partitioning Antoine <melser.anton@gmail.com>
2006-03-21 09:59 ` Re: partitioning Jim C. Nasby <jnasby@pervasive.com>
2006-12-26 18:36 Partitioning Kevin Hunter <hunteke@earlham.edu>
2006-12-26 19:55 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-12-26 22:29 ` Kevin Hunter <hunteke@earlham.edu>
2006-12-27 04:37 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-01-05 11:02 Partitioning Arnau <arnaulist@andromeiberica.com>
2007-01-05 11:47 Re: Partitioning Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
2007-01-10 20:20 ` Jim C. Nasby <jim@nasby.net>
2007-01-10 20:28 ` Jeremy Haile <jhaile@fastmail.fm>
2007-01-10 21:09 ` Jim C. Nasby <jim@nasby.net>
2007-01-10 21:15 ` Jeremy Haile <jhaile@fastmail.fm>
2007-01-10 21:51 ` Scott Marlowe <smarlowe@g2switchworks.com>
2007-01-10 21:30 ` Scott Marlowe <smarlowe@g2switchworks.com>
2007-01-11 12:51 ` Bernd Helmle <mailings@oopsware.de>
2007-01-11 14:18 ` Adam Rich <adam.r@sbcglobal.net>
2007-01-11 14:32 ` Bernd Helmle <mailings@oopsware.de>
2007-01-10 20:30 ` Erik Jones <erik@myemma.com>
2007-01-11 12:59 ` Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
2007-01-11 14:02 ` Jeremy Haile <jhaile@fastmail.fm>
2007-01-12 11:40 Partitioning Gauri Kanekar <meetgaurikanekar@gmail.com>
2007-01-30 07:10 ` Tomas Vondra <tv@fuzzy.cz>
2007-01-30 06:42 Partitioning Abu Mushayeed <abumushayeed@yahoo.com>
2007-01-30 10:21 ` Rigmor Ukuhe <rigmor.ukuhe@finestmedia.ee>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox