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
http://www.gunduz
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 ex
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 maint
Emmanuel Cecchet 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 pg_inherits and
> > dete
ITAGAKI Takahiro wrote:
Emmanuel Cecchet 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 to name
the trigger
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 c
Emmanuel Cecchet 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 expand all of child pa
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 refactori
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
On Mon, Dec 15, 2008 at 1:46 PM, Gregory Stark wrote:
> Josh Berkus 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-pa
Josh Berkus 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 generati
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)
T
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 requireme
> 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 p
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 all
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_da
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 t
>> 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
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 partitio
On Thu, Nov 27, 2008 at 8:07 AM, Robert Haas <[EMAIL PROTECTED]> wrote:
>
> The semantics of PARTITION ON () are unclear to me. I was
> thinking maybe it would make sense to do something like:
>
> CREATE PARTITION ON WHERE
>
At first look seems nice but s Gregory said the ideal would be to
ide
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
"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 diff
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 cor
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 o
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 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 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]
> '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 lo
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
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 ad
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 if
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 subs
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]> w
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 --
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
36 matches
Mail list logo
