Hey dear list,
I'd like to partition geographical (geometry) data with postgres mechanism.
(my usage is in fact related to pointcloud, but I use geometry as a work
around)
From example I read on constraint, nothing should prevent it from working
Here is a self contained example, the planner
Hi all,
I sent the following mail yesterday but I do not see it in the list.
So I retry
==
Hi,
I have created a partitionned table and a Pl/PgSQL trigger exactly as
explained
herehttp://www.postgresql.org/docs/9.2/static/ddl-partitioning.htmlin
the documentation.
It works fine but
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 as
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
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
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...):
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 up fkeys and
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
On Sun, 13 Mar 2005 00:18:39 +0100, Martijn van Oosterhout
kleptog@svana.org 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
Martijn van Oosterhout kleptog@svana.org 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
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 @
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
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 saying that
Title: iterate over refcursor
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 application store xml documents in
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
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
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 year
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
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 dramatic
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 system : it allows to spread
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 sitting
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 refrain to
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
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 it in
24 matches
Mail list logo
