Hello all, still with partitioning... wheter I use rules or triggers is there a way for me _not_ to specify field-by-field all the fields I wish to be redirected to the child-table... as example: instead of this: --------------------------------------------------------- create rule insert_t_1 AS ON INSERT TO teste WHERE (t>=1000 and t<2000) DO INSTEAD INSERT INTO t_1 VALUES (NEW.t, NEW.s1, NEW.s2 NEW.s3, NEW.s4 NEW.s5, NEW.s6, NEW.s7, NEW.s8); --------------------------------------------------------- something like this: --------------------------------------------------------- create rule insert_t_1 AS ON INSERT TO teste WHERE (t>=1000 and t<2000) DO INSTEAD INSERT INTO t_1 VALUES (__ALL__); --------------------------------------------------------- of course this assumes that the child table inherits all fields from the parent table _and_ has no extra fields which is exactly my case. any hints. thx j On Sat, 2008-09-13 at 16:48 -0400, Robert Treat wrote: > On Thursday 11 September 2008 07:47:00 Joao Ferreira gmail wrote: > > Hello all, > > > > my application is coming to a point on which 'partitioning' seems to be > > the solution for many problems: > > > > - query speed up > > - data elimination speed up > > > > I'dd like to get the feeling of it by talking to people who use > > partitioning, in general.. > > > > - good, bad, > > good :-) > > > - hard to manage, easy to manage, > > I think the upfront costs for managing a partitioning setup are higher with > postgres than other systems, but there is nothing that you shouldn't be able > to automate in a cron script (at which point management becomes easy), plus > postgres gives you some interesting flexibility that is harder to find in > other setups. > > > - processing over-head during INSERT/UPDATE, > > you can setup inserts to have relativly little overhead, but it requires more > management/maintence work up front. Updates within a partition also have > relativly little extra overhead, especially if you put in a little > application logic to figure out how to work on a partition directly. Updates > where you are changing the partition key value are always more problematic > though. > > > - stability/compatibility of pg_dump and restore operations, > > no real issues here as long as your on recent enough versions to do wildcard > table matching for individual tables. > > > - how many partitions would be reasonable for read _and_ write access > > optimal speed; > > > > again, this depends on how exactly your working on the data. For example, we > have tables with over a thousand partitions on them; in those scenarios all > data is written into a single partition (with a new partition created daily), > and the qeury patterns are really straightforward... last month gets a lot of > queries, lasat three months not so much, last year barely any, and beyond > that is pretty much just archive info. That said, we have other systems where > that wouldnt work at all (for example, a static number of partitions, all of > which are queried activly). > > For some more info, I've given at least one presentation on the topic, which > seems to be missing from the omniti site, but I've uploaded it to > slideshare... > http://www.slideshare.net/xzilla/postgresql-partitioning-pgcon-2007-presentation > > HTH. >
