pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feeddb performance/design question
2+ messages / 2 participants
[nested] [flat]
* db performance/design question
@ 2007-09-12 20:33 Matt Chambers <chambers@imageworks.com>
2007-09-12 21:58 ` Re: db performance/design question Scott Marlowe <scott.marlowe@gmail.com>
0 siblings, 1 reply; 2+ messages in thread
From: Matt Chambers @ 2007-09-12 20:33 UTC (permalink / raw)
To: pgsql-performance
I'm designing a system that will be doing over a million inserts/deletes
on a single table every hour. Rather than using a single table, it is
possible for me to partition the data into multiple tables if I wanted
to, which would be nice because I can just truncate them when I don't
need them. I could even use table spaces to split the IO load over
multiple filers. The application does not require all this data be in
the same table. The data is fairly temporary, it might last 5 seconds,
it might last 2 days, but it will all be deleted eventually and
different data will be created.
Considering a single table would grow to 10mil+ rows at max, and this
machine will sustain about 25mbps of insert/update/delete traffic 24/7 -
365, will I be saving much by partitioning data like that?
--
-Matt
<http://twiki.spimageworks.com/twiki/bin/view/Software/CueDevelopment;
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: db performance/design question
2007-09-12 20:33 db performance/design question Matt Chambers <chambers@imageworks.com>
@ 2007-09-12 21:58 ` Scott Marlowe <scott.marlowe@gmail.com>
0 siblings, 0 replies; 2+ messages in thread
From: Scott Marlowe @ 2007-09-12 21:58 UTC (permalink / raw)
To: chambers@imageworks.com; +Cc: pgsql-performance
On 9/12/07, Matt Chambers <chambers@imageworks.com> wrote:
>
>
> I'm designing a system that will be doing over a million inserts/deletes on
> a single table every hour. Rather than using a single table, it is possible
> for me to partition the data into multiple tables if I wanted to, which
> would be nice because I can just truncate them when I don't need them. I
> could even use table spaces to split the IO load over multiple filers. The
> application does not require all this data be in the same table. The data
> is fairly temporary, it might last 5 seconds, it might last 2 days, but it
> will all be deleted eventually and different data will be created.
>
> Considering a single table would grow to 10mil+ rows at max, and this
> machine will sustain about 25mbps of insert/update/delete traffic 24/7 -
> 365, will I be saving much by partitioning data like that?
This is the exact kind of application for which partitioning shines,
especially if you can do the inserts directly to the partitions
without having to create rules or triggers to handle it. If you have
to point at the master table, stick to triggers as they're much more
efficient at slinging data to various sub tables.
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2007-09-12 21:58 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2007-09-12 20:33 db performance/design question Matt Chambers <chambers@imageworks.com>
2007-09-12 21:58 ` Scott Marlowe <scott.marlowe@gmail.com>
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