Robert Haas wrote:
> David Fetter wrote:
>> Does The Standard* have anything to say?
>
> I don't know
I dug around in the standard a bit and didn't find anything. Given
that the standard doesn't even touch the issue of indexes because
that a performance tuning implementation detail, it woul
On Tue, Jun 21, 2011 at 1:52 PM, David Fetter wrote:
>> Still, I think a pretty clear
>> way forward here is to try to figure out a way to add some explicit
>> syntax for range partitions, so that you can say...
>>
>> foo_a is for all rows where foo starts with 'a'
>> foo_b is for all rows where f
On Tue, Jun 21, 2011 at 01:07:17PM -0400, Robert Haas wrote:
> On Mon, Jun 20, 2011 at 5:42 PM, David Fetter wrote:
> > I noticed that we have some nice new speed optimizations (more
> > properly, de-pessimizations) for partitioned tables in 9.1.
>
> /me sticks tongue out at dfetter.
>
> > Anybo
On Mon, Jun 20, 2011 at 5:42 PM, David Fetter wrote:
> I noticed that we have some nice new speed optimizations (more
> properly, de-pessimizations) for partitioned tables in 9.1.
/me sticks tongue out at dfetter.
> Anybody care to look over the table partitioning stuff on the wiki and
> check i
Folks,
I noticed that we have some nice new speed optimizations (more
properly, de-pessimizations) for partitioned tables in 9.1.
Anybody care to look over the table partitioning stuff on the wiki and
check it for relevance?
http://wiki.postgresql.org/wiki/Table_partitioning
I think I may be ab
Igor Kryltsov wrote:
I am not asking any firm dates but when (and if) do you think roughly
it will be any enhancements on automating partitioning in Postgres?
The earliest possible date for that is the summer of 2011 when
PostgreSQL 9.1 might be released:
http://wiki.postgresql.org/wiki/P
Hi Robert,
> I am a little fuzzy on what you're proposing here, but I think you're
> saying that you're only going to support range partitioning on
> integers or dates and that you plan to use the text type to store the
> integer or date values. FWIW, those don't seem like very good
> decisio
Thanks for your feedback, Emmanuel.
Here are my comments:
On 2/10/09, Emmanuel Cecchet wrote:
> Hi Amit,
>
> I will be traveling until next Tuesday and will have no access to email so
> don't be surprised if I don't follow up this week.
> The overall approach seems sound. The metadata table sho
On Mon, Feb 9, 2009 at 9:16 AM, Amit Gupta wrote:
> Hi Emmanuel,
>
> We are considering to following approach:
> 1. metadata table pg_partitions is defined as follows:
> CATALOG(pg_partitions,2336) BKI_WITHOUT_OIDS
> {
>Oid partrelid; // partition table Oid
>Oid parentr
Hi Amit,
I will be traveling until next Tuesday and will have no access to email
so don't be surprised if I don't follow up this week.
The overall approach seems sound. The metadata table should help also
for DDL to find out overlapping ranges or duplicate list entries.
So far, I have not tried
Hi Emmanuel,
We are considering to following approach:
1. metadata table pg_partitions is defined as follows:
CATALOG(pg_partitions,2336) BKI_WITHOUT_OIDS
{
Oid partrelid; // partition table Oid
Oid parentrelid; // Parent table Oid
int4parttype; // Type o
Hi Emmanuel,
On 1/26/09, Emmanuel Cecchet wrote:
>
> Hi Amit,
>
> I overlooked the fact that you dropped composite partitions and
> subpartitions template from the proposal presented in
> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php.
> Is it because this is too hard to suppo
Hi Amit,
I overlooked the fact that you dropped composite partitions and
subpartitions template from the proposal presented in
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php.
Is it because this is too hard to support? or you don't see any
immediate need for it?
Thanks,
Emm
Hi Emmanuel,
Please find my comments in-lined:
On 1/23/09, Emmanuel Cecchet wrote:
>
> Amit,
>
> You might want to put this on the
> http://wiki.postgresql.org/wiki/Table_partitioning wiki page.
Sure.
How does your timeline look like for this implementation?
The implementation is planned a
Amit,
You might want to put this on the
http://wiki.postgresql.org/wiki/Table_partitioning wiki page.
How does your timeline look like for this implementation?
I would be happy to contribute C triggers to your implementation. From
what I understood in
http://archives.postgresql.org/pgsql-hack
Amit,
Wow, thanks!
As you probably know, we're already in freeze for 8.4. So this patch
will need to go on the first commitfest for 8.5, in May or June.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
Hi,
We are implementing table partitioning feature to support
- the attached commands. The syntax conforms to most of the suggestion
mentioned in
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php, barring
the following:
-- Specification of partition names is optional. System will b
Dropping -hackers; that list is for development of the database
engine itself.
The problem is that rules will happen before triggers, so what you're
trying to do will never work. Instead, just have the trigger insert
the data into the appropriate table.
On May 30, 2007, at 9:55 AM, Enrico
Hello,
I'm trying to write a trigger on insert which should insert the row
in another
table. The table on which to insert the row should be selected at
runtime and
it is not know in advance. For example, let's say we have a table with
two columns, a date and an integer. a row is inserted int
Paolo Magnoli wrote:
> Hi, I seem to recall that in Oracle you load into specific partitions
> without specifically naming them in insert statements (in other words you
> insert into table, the engine redirects data to the corrisponding
> partition),
This is correct
--
__
On Fri, 2005-09-23 at 12:30 +0200, Paolo Magnoli wrote:
> It would be good to have an insert behaviour similar to Oracle by default.
OK, thanks.
> Also I see that the original table is always scanned, partition exclusion
> happens only on the derived tables, is this correct?
Yes, though if you
> -Messaggio originale-
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] conto di Simon Riggs
> Inviato: venerdì 23 settembre 2005 11.51
> A: Jim C. Nasby
> Cc: Tom Lane; pgsql-hackers@postgresql.org
> Oggetto: Re: [HACKERS] Table Partitioning is in 8.1
>
>
> On Thu, 20
On Thu, 2005-09-22 at 14:37 -0500, Jim C. Nasby wrote:
> On Thu, Sep 22, 2005 at 10:11:50AM +0100, Simon Riggs wrote:
> > On Wed, 2005-09-21 at 15:39 -0400, Tom Lane wrote:
> > > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > > Is it possible that the Release Notes do not fully explain the
> > > > C
Simon Riggs wrote:
> On Wed, 2005-09-21 at 15:39 -0400, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > Is it possible that the Release Notes do not fully explain the
> > > Constraint Exclusion feature? Or is it the consensus that it works but
> > > not quite well enough to make a
Word "basic" added.
---
Joshua D. Drake wrote:
> >
> > On reflection, the only changes I suggest are:
> >
> > 1) the phrase "This allows for a type of table partitioning" have the
> > word "basic" inserted within it to bec
On reflection, the only changes I suggest are:
1) the phrase "This allows for a type of table partitioning" have the
word "basic" inserted within it to become: "This allows for a basic type
of table partitioning"
How about just: Initial support for table partitioning. Yes it is
non-committal
On Thu, Sep 22, 2005 at 10:11:50AM +0100, Simon Riggs wrote:
> On Wed, 2005-09-21 at 15:39 -0400, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > Is it possible that the Release Notes do not fully explain the
> > > Constraint Exclusion feature? Or is it the consensus that it works
On Wed, 2005-09-21 at 15:39 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Is it possible that the Release Notes do not fully explain the
> > Constraint Exclusion feature? Or is it the consensus that it works but
> > not quite well enough to make a song and dance about yet?
>
On K, 2005-09-21 at 15:39 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Is it possible that the Release Notes do not fully explain the
> > Constraint Exclusion feature? Or is it the consensus that it works but
> > not quite well enough to make a song and dance about yet?
>
>
On K, 2005-09-21 at 18:10 +0100, Simon Riggs wrote:
> Table Partitioning is in 8.1
>
> I've just read Peter Eisentraut's presentation to the Dutch gov (very
> good BTW). On the last page I read that Table Partitioning is a future
> for PostgreSQLwhich is strange because Constraint Exclusion is
Simon Riggs <[EMAIL PROTECTED]> writes:
> Is it possible that the Release Notes do not fully explain the
> Constraint Exclusion feature? Or is it the consensus that it works but
> not quite well enough to make a song and dance about yet?
I hardly think that the existing constraint-exclusion code i
On Wed, Sep 21, 2005 at 06:10:15PM +0100, Simon Riggs wrote:
> Table Partitioning is in 8.1
>
> I've just read Peter Eisentraut's presentation to the Dutch gov (very
> good BTW). On the last page I read that Table Partitioning is a future
> for PostgreSQLwhich is strange because Constraint Exc
Table Partitioning is in 8.1
I've just read Peter Eisentraut's presentation to the Dutch gov (very
good BTW). On the last page I read that Table Partitioning is a future
for PostgreSQLwhich is strange because Constraint Exclusion is an
8.1 feature.
I've had five other people ask about it too
On T, 2005-05-10 at 23:09 +0100, Simon Riggs wrote:
> On Tue, 2005-05-10 at 16:31 +0300, Hannu Krosing wrote:
> > > If all partitions in the query had identical indexes on them, then we
> > > have another option. In that case, each index could be thought to form
> > > part of a larger index ordere
On Tue, 2005-05-10 at 15:01 -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Tue, May 10, 2005 at 12:16:17AM +0100, Simon Riggs wrote:
> >> On Mon, 2005-05-09 at 18:53 -0400, Tom Lane wrote:
> >>> I disagree. The code is there, it could use work, and what you are
> >>> ba
On Tue, 2005-05-10 at 16:44 +0300, Hannu Krosing wrote:
> On T, 2005-05-10 at 16:31 +0300, Hannu Krosing wrote:
> > On E, 2005-05-09 at 23:30 +0100, Simon Riggs wrote:
>
> > There are 2 possibly expensive steps:
> >
> > 1. the conversion to "AND'ed list of simple clauses" (unknown
> > complexity
On Tue, 2005-05-10 at 16:31 +0300, Hannu Krosing wrote:
> On E, 2005-05-09 at 23:30 +0100, Simon Riggs wrote:
> > ISTM fairly straightforward to produce a similar "static" plan along the
> > same lines, using Result nodes to implement Partition Elimination.
> >
> > Append
> > Result
> > SeqS
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Tue, May 10, 2005 at 12:16:17AM +0100, Simon Riggs wrote:
>> On Mon, 2005-05-09 at 18:53 -0400, Tom Lane wrote:
>>> I disagree. The code is there, it could use work, and what you are
>>> basically proposing is to duplicate both the existing work and
On Tue, May 10, 2005 at 12:16:17AM +0100, Simon Riggs wrote:
> On Mon, 2005-05-09 at 18:53 -0400, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > 1. Embellish inheritance or separate infrastructure?
> >
> > > It seems prudent to avoid building on that foundation, even though we
>
On T, 2005-05-10 at 16:31 +0300, Hannu Krosing wrote:
> On E, 2005-05-09 at 23:30 +0100, Simon Riggs wrote:
> There are 2 possibly expensive steps:
>
> 1. the conversion to "AND'ed list of simple clauses" (unknown
> complexity)
>
> 2. matching each of "simple" clauses in the and list with all
On E, 2005-05-09 at 23:30 +0100, Simon Riggs wrote:
> A more in-depth consideration of the major design options and trade-offs
> available to us... this is an internals related discussion.
>
> Comments?
>
> 1. Embellish inheritance or separate infrastructure?
>
> Inheritance is a somewhat strang
Tom Lane <[EMAIL PROTECTED]> writes:
> > Partition Elimination relies upon being able to prove at execution time
>
> You mean plan time.
Fwiw, both are possible.
In oracle there are (at least) three different cases:
1. For queries like "select * from tab" the plan shows a multiple partition
sc
On Mon, 2005-05-09 at 18:53 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > 1. Embellish inheritance or separate infrastructure?
>
> > It seems prudent to avoid building on that foundation, even though we
> > may decide to use some similar approaches.
>
> I disagree. The cod
Simon Riggs <[EMAIL PROTECTED]> writes:
> 1. Embellish inheritance or separate infrastructure?
> It seems prudent to avoid building on that foundation, even though we
> may decide to use some similar approaches.
I disagree. The code is there, it could use work, and what you are
basically proposi
A more in-depth consideration of the major design options and trade-offs
available to us... this is an internals related discussion.
Comments?
1. Embellish inheritance or separate infrastructure?
Inheritance is a somewhat strange PostgreSQL feature, with a few
gotchas. The "big one" is the lack
Many people have been discussing Table Partitioning lately. I've also
been giving thought to how to implement Table Partitioning within
PostgreSQL, as part of the Bizgres project for Business Intelligence.
After some discussion on Bizgres, I've now posted the most important and
common Use Cases f
I'm not subscribed to this list, so please CC me on replies.
I wanted to know when table partitioning was supposed to be completed. I
was under the impression that work had been done about 5 months ago or
more and that all that was needed was testing. Could someone please
advise?
We're looking at
> As people who are needing to move away from Oracle due to cost
> restrictions, I wanted to know how much work, or what the status is of
> this option. Please respond asap if possible. I have to give my VP info
> on this relatively soon.
A lot of work is needed, and I wouldnt' even guarantee it
I seem to recall that Table partitioning used to be on the *urgent*
heading of the ToDo list. Now I see it is under misc.
As people who are needing to move away from Oracle due to cost
restrictions, I wanted to know how much work, or what the status is of
this option. Please respond asap if possi
49 matches
Mail list logo
