snip
Is there any progress on this patch? I was asked about this feature last
month, during a PostgreSQL talk. I am willing to spend time for testing
this patch, if needed.
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
ITAGAKI Takahiro wrote:
The chained triggers would have better flexibilty, and the auto expanding
trigger would have better usability. I'm not sure about performance
because expanding child partitions is not always faster than chained
calls of triggers.
I think chained triggers are hard to
On 2008-12-16, at 07:58, ITAGAKI Takahiro wrote:
server says INSERT 0 row though rows are inserted into child
tables.
Technically this is correct since 0 rows were inserted in the parent
table.
Yes, but users expect non-0 result normally. Some O/R mapping tools
also checks the result
Hackers,
We don't yet seem to have a clear specification for this feature, and
the Other Open Source DB has shown us how problematic it is to get
auto-partitioning wrong.
Should we defer auto-partitioning to 8.5?
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Josh Berkus j...@agliodbs.com writes:
Hackers,
We don't yet seem to have a clear specification for this feature, and the
Other
Open Source DB has shown us how problematic it is to get auto-partitioning
wrong.
Should we defer auto-partitioning to 8.5?
If we're serious about having a next
On Mon, Dec 15, 2008 at 1:46 PM, Gregory Stark st...@enterprisedb.com wrote:
Josh Berkus j...@agliodbs.com writes:
Hackers,
We don't yet seem to have a clear specification for this feature, and the
Other
Open Source DB has shown us how problematic it is to get auto-partitioning
wrong.
Hi all,
I will be working on a roadmap for the partitioning features. I think
that there are different needs and that we will not be able to address
them all in 8.5 or even 8.6.
The goal will be to get things done step by step but possibly with a
design that will not require major refactoring
Hi,
I will be working on a roadmap for the partitioning features. I think that
there are different needs and that we will not be able to address them all
in 8.5 or even 8.6.
The goal will be to get things done step by step but possibly with a design
that will not require major refactoring
Emmanuel Cecchet m...@frogthinker.org wrote:
In the meantime, I have made some more tests with the trigger in C (see
attached patch).
Hmm... The inserting partition is passed by trigger arguments.
Users must replace triggers when the target is changed (ex. every month).
Is it possible to
Nikhil Sontakke wrote:
A similar DELETE trigger should be pretty easy to write up in C. I
think the main challenge is with UPDATE triggers especially if the new
row will fall into another child table - but we can always throw an
error for such a case initially.
I agree. A first implementation
ITAGAKI Takahiro wrote:
Emmanuel Cecchet m...@frogthinker.org wrote
In the meantime, I have made some more tests with the trigger in C (see
attached patch).
Hmm... The inserting partition is passed by trigger arguments.
Actually this is just a fallback option. The preferred option is
Emmanuel Cecchet m...@frogthinker.org wrote:
I think there is a misunderstanding on how the trigger works. You have 1
trigger per child table and they are all chained on the parent table.
Oops, I misunderstand your patch, sorry.
Is it possible to expand all of child paritions from
Hi all,
While I was trying to find the right place to add a new page on the
wiki, I found the document of Simon on partitioning requirements
(http://wiki.postgresql.org/wiki/Image:Partitioning_Requirements.pdf)
referenced from http://wiki.postgresql.org/wiki/Development_projects
I think this
On Thu, Nov 27, 2008 at 11:09 AM, Emmanuel Cecchet [EMAIL PROTECTED] wrote:
I have been following that discussion very closely but it seems that we are
debating solutions without a good specification of the problem/requirements.
I would suggest that we collect all the partitioning requirements
Hi,
i review it on nov 6, and there were open questions by me and by
Emmanuel none of those has been answered:
http://archives.postgresql.org/pgsql-hackers/2008-11/msg00362.php
Hmm, there's only one actual question in that email, which is a
request for ideas about PL/pgsql vs. C. I
Nikhil Sontakke escribió:
The status has always being WIP, because what has not happened is that we
have not had consensus on whether this is a logical first baby step ahead
with partitioning. I haven't seen core members commenting on whether trying
to aggregate the current set of manual
On Thu, Nov 27, 2008 at 7:04 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Nikhil Sontakke escribió:
The status has always being WIP, because what has not happened is that we
have not had consensus on whether this is a logical first baby step ahead
with partitioning. I haven't seen core members
Robert Haas [EMAIL PROTECTED] writes:
CREATE PARTITION transaction_2008_11 ON transaction WHERE record_date
BETWEEN '2008-11-01' AND '2008-11-30';
I think the main advantage to a better partitioning method would be teaching
Postgres about the partition key. Instead of a collection of different
Hi,
The status has always being WIP, because what has not happened is that we
have not had consensus on whether this is a logical first baby step ahead
with partitioning. I haven't seen core members commenting on whether
trying
to aggregate the current set of manual operations together
On Thu, Nov 27, 2008 at 8:07 AM, Robert Haas [EMAIL PROTECTED] wrote:
The semantics of PARTITION ON (expr) are unclear to me. I was
thinking maybe it would make sense to do something like:
CREATE PARTITION name ON table WHERE expr
At first look seems nice but s Gregory said the ideal would
On Thu, Nov 27, 2008 at 8:31 AM, Gregory Stark [EMAIL PROTECTED] wrote:
CREATE PARTITION transaction_2008_11 ON transaction WHERE record_date
BETWEEN '2008-11-01' AND '2008-11-30';
I think the main advantage to a better partitioning method would be teaching
Postgres about the partition key.
I like the idea of using table inheritance as a foundation for this
feature, but I think it's not going to be very useful for real-world
applications without cross-table indexes. Suppose for example that I
have five years worth of data (thus, 60 partitions) and each
transaction has a unique
On Thu, Nov 27, 2008 at 9:41 AM, Robert Haas [EMAIL PROTECTED] wrote:
On Thu, Nov 27, 2008 at 8:31 AM, Gregory Stark [EMAIL PROTECTED] wrote:
CREATE PARTITION transaction_2008_11 ON transaction WHERE record_date
BETWEEN '2008-11-01' AND '2008-11-30';
I think the main advantage to a better
On Thu, Nov 27, 2008 at 10:10 AM, Jaime Casanova
[EMAIL PROTECTED] wrote:
On Thu, Nov 27, 2008 at 9:41 AM, Robert Haas [EMAIL PROTECTED] wrote:
On Thu, Nov 27, 2008 at 8:31 AM, Gregory Stark [EMAIL PROTECTED] wrote:
CREATE PARTITION transaction_2008_11 ON transaction WHERE record_date
BETWEEN
Hi all,
I have been following that discussion very closely but it seems that we
are debating solutions without a good specification of the
problem/requirements.
I would suggest that we collect all the partitioning requirements on a
dedicated Wiki page. There might not be a one size fits it
ok. what about let CREATE TABLE WITH PARTITIONING to create an entry
in a catalog indicating the key of the partition and install the
triggers and let the trigger decide if it has the partition to insert
the new row (making UPDATE working almost as DELETE+INSERT if it needs
to change of
On Wed, Nov 5, 2008 at 11:47 PM, Jaime Casanova
[EMAIL PROTECTED] wrote:
On Fri, Oct 31, 2008 at 7:42 PM, Emmanuel Cecchet [EMAIL PROTECTED] wrote:
Hi Nikhil,
i'm looking at this one:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
'cause the great interest this one has (i'm
'cause the great interest this one has (i'm being ironic, just in case
;) can we safely say this was returned with feedback and remove it
from the list of pending patches?
Um... are you referring to lack of interest from the patch author, or
from the community?
If the patch author is no
On Wed, Nov 26, 2008 at 10:52 PM, Robert Haas [EMAIL PROTECTED] wrote:
'cause the great interest this one has (i'm being ironic, just in case
;) can we safely say this was returned with feedback and remove it
from the list of pending patches?
the patch is on the
commitfest wiki[1] and you
i review it on nov 6, and there were open questions by me and by
Emmanuel none of those has been answered:
http://archives.postgresql.org/pgsql-hackers/2008-11/msg00362.php
Hmm, there's only one actual question in that email, which is a
request for ideas about PL/pgsql vs. C. I suspect you
On Fri, Oct 31, 2008 at 7:42 PM, Emmanuel Cecchet [EMAIL PROTECTED] wrote:
Hi Nikhil,
i'm looking at this one:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
Here are a couple of questions:
- How do you ALTER the table to repartition it?
fair question. but the patch was
Hi,
Thanks for taking a look. But if I am not mistaken Gavin and co.
are
working
on a much exhaustive proposal. In light of that maybe this patch
might
not
be needed in the first place?
I will wait for discussion and a subsequent collective consensus
here,
Hi Nikhil,
Here are a couple of questions:
- How do you ALTER the table to repartition it?
- The trigger function for inserts could be improved by using ELSE
instead of independent IFs. This would ensure that the row is inserted
in at most 1 partition. The last ELSE should raise an exception
Hi,
On Wed, Oct 22, 2008 at 8:14 PM, Jaime Casanova
[EMAIL PROTECTED] wrote:
just remembering that -patches is a dead list, so i'm sending this to
-hackers where it will have more visibility...
-- Forwarded message --
On 10/22/08, Nikhil Sontakke [EMAIL PROTECTED] wrote:
just remembering that -patches is a dead list, so i'm sending this to
-hackers where it will have more visibility...
-- Forwarded message --
From: Jaime Casanova [EMAIL PROTECTED]
Date: Oct 22, 2008 9:43 AM
Subject: Re: [PATCHES] Auto Partitioning Patch - WIP version 1
To: Nikhil
Another advantage of triggers over rules is that it would work with COPY
which is probably a desired feature.
Emmanuel
Jaime Casanova wrote:
just remembering that -patches is a dead list, so i'm sending this to
-hackers where it will have more visibility...
-- Forwarded message
36 matches
Mail list logo
