Ali Pouya wrote:
> I sent the following mail yesterday but I do not see it in the list.
> So I retry
It is there all right:
http://www.postgresql.org/message-id/CAEEEPmwq_3=hGEC69-2EkCWTiwq0dme==8sou29e9k2dccg...@mail.gmail.com
> I have created a partitionned table and a Pl/PgSQL trigger exactly
On Sat, Mar 12, 2005 at 11:35:51PM -0500, Tom Lane wrote:
> The issue isn't really whether the planner *could* use a constraint
> to decide that a table need not be scanned at all. As you say, we
> have practically all the infrastructure needed for such inferences.
> To me the real reason why we d
Martijn van Oosterhout writes:
> Note, the planner does have most of the intelligence needed to
> determine when it can skip a partition.
The issue isn't really whether the planner *could* use a constraint
to decide that a table need not be scanned at all. As you say, we
have practically all the
On Sun, 13 Mar 2005 00:18:39 +0100, Martijn van Oosterhout
wrote:
> On Sat, Mar 12, 2005 at 08:24:20PM +, Mike Rylander wrote:
> > There is now way to have PG completely skip the unused partitions.
> > However, with an index on the "partitioner" column of each partition
> > table PG will basic
On Sat, Mar 12, 2005 at 08:24:20PM +, Mike Rylander wrote:
> There is now way to have PG completely skip the unused partitions.
> However, with an index on the "partitioner" column of each partition
> table PG will basically fall of the end of the index almost
> imediately, and then use an app
On Sat, 12 Mar 2005 17:39:38 +0100 (CET), Christian Kratzer
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Sat, 12 Mar 2005, Mike Rylander wrote:
>
> > Back to the original question on this thread, and using PG 8.0.1.
> > Perhaps someone would like to poke holes in this (other than the need
> > to set u
Hi,
On Sat, 12 Mar 2005, Mike Rylander wrote:
Back to the original question on this thread, and using PG 8.0.1.
Perhaps someone would like to poke holes in this (other than the need
to set up fkeys and indexes on the inherited tables...):
Back to the original question on this thread, and using PG 8.0.1.
Perhaps someone would like to poke holes in this (other than the need
to set up fkeys and indexes on the inherited tables...):
---
begin;
create schema pa
> Actually I have a strong feeling what really _ought_ to happen here is that
> the inherited tables support in postgres, which never really worked anyways,
> should be deprecated and eventually removed.
Hopefully not. They are useful for other things, too.
Karsten
--
GPG key ID E4071346 @ wwwkey
On Wed, 2005-03-09 at 17:29, Greg Stark wrote:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
> > But what I'm really saying is that between good home grown partitioning
> > and fast hardware, the need for the pg devel team to implement
> > partitioning is pretty low.
>
> Ah. I thought you were sayi
Greg Stark wrote:
Actually I have a strong feeling what really _ought_ to happen here is that
the inherited tables support in postgres, which never really worked anyways,
should be deprecated and eventually removed. All that infrastructure should be
repurposed into partitioned tables. That seems li
Scott Marlowe <[EMAIL PROTECTED]> writes:
> Yes, it is a way. It's just a less necessary one than it once was, with
> hardware now able to provide the same performance increase with little
> or no work on the users part. We've got to weigh the increased
> complexity it would take to implement i
Scott Marlowe <[EMAIL PROTECTED]> writes:
> Wait, I'm not sure I understand your point here yet. Are you saying
> something along the lines of that with a 1TB storage array, and putting
> all the data in one big partitions, the DBAs had problems, but when they
> partitioned it down to say 10 100G
On Wed, 2005-03-09 at 14:47, Greg Stark wrote:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
>
> > Actually, I think it is the more common scenario of migrating off of
> > oracle or db2 and onto postgresql, and bringing along the experience
> > gained there over the years that has caused this refrai
Scott Marlowe <[EMAIL PROTECTED]> writes:
> Actually, I think it is the more common scenario of migrating off of
> oracle or db2 and onto postgresql, and bringing along the experience
> gained there over the years that has caused this refrain to sprout up
> more and more often. With a database si
On Wed, 2005-03-09 at 13:21, Joshua D. Drake wrote:
> Scott Marlowe wrote:
>
> >On Wed, 2005-03-09 at 10:31, FERREIRA William (COFRAMI) wrote:
> >
> >
> >>hi
> >>
> >>does the table partitionning exists under PostgreSQL ? or maybe an
> >>alternative exists ?
> >>
> >>Oracle implements this sys
On Wed, 2005-03-09 at 13:07, Greg Stark wrote:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
>
> > With the advent of very large raid arrays with very fast caching
> > controllers, this methodology is becoming less and less necessary.
>
> I think the evidence is to the contrary. Witness the rather
Scott Marlowe wrote:
On Wed, 2005-03-09 at 10:31, FERREIRA William (COFRAMI) wrote:
hi
does the table partitionning exists under PostgreSQL ? or maybe an
alternative exists ?
Oracle implements this system : it allows to spread rows on differents
partitions depending on an attribute.
For example,
Scott Marlowe <[EMAIL PROTECTED]> writes:
> With the advent of very large raid arrays with very fast caching
> controllers, this methodology is becoming less and less necessary.
I think the evidence is to the contrary. Witness the rather dramatic surge in
inquiries about this on this list. A yea
Tablespaces are the closest thing. They were introduced in 8.0:
http://www.postgresql.org/docs/8.0/static/sql-createtablespace.html
-tfo
--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-00
On Wed, 2005-03-09 at 10:31, FERREIRA William (COFRAMI) wrote:
> hi
>
> does the table partitionning exists under PostgreSQL ? or maybe an
> alternative exists ?
>
> Oracle implements this system : it allows to spread rows on differents
> partitions depending on an attribute.
> For example, my
21 matches
Mail list logo
