Martijn van Oosterhout writes:
> That said, I still don't see how you can enforce a unique index over
> multiple segments over something other than the partition key while
> still allowing quick dropping of segments. If you can fix that you can
> make it work for the current inheritence-style par
On Mon, Nov 14, 2011 at 10:33:36AM +0100, Dimitri Fontaine wrote:
> Martijn van Oosterhout writes:
> > While I agree that explicit partitioning is somewhat of a hack, it's a
> > really useful hack. But for me the most important use of partitioning
> > is "dropping a billion rows efficiently and g
Martijn van Oosterhout writes:
> While I agree that explicit partitioning is somewhat of a hack, it's a
> really useful hack. But for me the most important use of partitioning
> is "dropping a billion rows efficiently and getting the disk space
> back". And the biggest problem is always that dro
Tom Lane writes:
> to match the desired granularity of data removal. I don't really see
> any way that the database can be expected to know what that is, unless
> it's told in advance. So AFAICS you really have to have a declarative
> way of telling it how to do the partitioning --- it's not goi
Martijn van Oosterhout writes:
> While I agree that explicit partitioning is somewhat of a hack, it's a
> really useful hack. But for me the most important use of partitioning
> is "dropping a billion rows efficiently and getting the disk space
> back".
Right. The only way to make that speedy i
On Thu, Nov 10, 2011 at 10:19:02PM +0100, Dimitri Fontaine wrote:
> Now the aim would be to be able to implement the operation you describe
> by using the new segment map, which is an index pointing to sequential
> ranges of on-disk blocks where the data is known to share a common key
> range over
On Thu, Nov 10, 2011 at 1:19 PM, Dimitri Fontaine
wrote:
> Now the aim would be to be able to implement the operation you describe
> by using the new segment map, which is an index pointing to sequential
> ranges of on-disk blocks where the data is known to share a common key
> range over the colu
Jeff Janes writes:
> shouldn't it need a DBA to declare it? How is the system supposed to
> anticipate that at some point years in the future I will want to run
> the command sequence "create foo_archive as select from foo where
> year<2009; delete from foo where year<2009", or its partition-base
On Wed, Nov 9, 2011 at 1:05 PM, Dimitri Fontaine wrote:
> Thom Brown writes:
>> Whenever I cross the topic of
>> partitioning in PostgreSQL, it's always a tad embarrassing to explain
>> that it's still hacky compared to other database systems (and this
>> came up again last week), so this is of p
On 11/09/2011 04:05 PM, Dimitri Fontaine wrote:
The more I think about this problem, the more I think that the reason
why we still don't have declarative partitioning is that it basically
sucks.
I think that we don't have it because no one has ever dumped the much
larger than might be expected
On 9 November 2011 21:05, Dimitri Fontaine wrote:
> Thom Brown writes:
>> Whenever I cross the topic of
>> partitioning in PostgreSQL, it's always a tad embarrassing to explain
>> that it's still hacky compared to other database systems (and this
>> came up again last week), so this is of particu
Thom Brown writes:
> Whenever I cross the topic of
> partitioning in PostgreSQL, it's always a tad embarrassing to explain
> that it's still hacky compared to other database systems (and this
> came up again last week), so this is of particular interest to me. At
The more I think about this prob
On 9 November 2011 15:15, Robert Haas wrote:
> On Wed, Nov 9, 2011 at 9:35 AM, Jaime Casanova wrote:
>> On Wed, Nov 9, 2011 at 8:26 AM, Thom Brown wrote:
>>>
>>> So will this be revived any time soon? Were there any subsequent
>>> proposals which were posted?
>>>
>>
>> there was an updated patc
On Wed, Nov 9, 2011 at 9:35 AM, Jaime Casanova wrote:
> On Wed, Nov 9, 2011 at 8:26 AM, Thom Brown wrote:
>>
>> So will this be revived any time soon? Were there any subsequent
>> proposals which were posted?
>>
>
> there was an updated patch, you can find in this thread:
> http://archives.postg
On Wed, Nov 9, 2011 at 8:26 AM, Thom Brown wrote:
>
> So will this be revived any time soon? Were there any subsequent
> proposals which were posted?
>
there was an updated patch, you can find in this thread:
http://archives.postgresql.org/message-id/20100114181323.9a33.52131...@oss.ntt.co.jp
n
On 15 December 2009 02:31, Jaime Casanova wrote:
> On Mon, Dec 14, 2009 at 7:29 PM, Simon Riggs wrote:
>> On Fri, 2009-12-04 at 09:00 +, Simon Riggs wrote:
>>> On Fri, 2009-12-04 at 11:54 +0900, Itagaki Takahiro wrote:
>>> > Here is an update partitioning syntax patch.
>>> >
>>> > A bug repor
On Mon, Dec 14, 2009 at 7:29 PM, Simon Riggs wrote:
> On Fri, 2009-12-04 at 09:00 +, Simon Riggs wrote:
>> On Fri, 2009-12-04 at 11:54 +0900, Itagaki Takahiro wrote:
>> > Here is an update partitioning syntax patch.
>> >
>> > A bug reported by Marko is fixed.
>>
>> I will review and eventually
On Fri, 2009-12-04 at 09:00 +, Simon Riggs wrote:
> On Fri, 2009-12-04 at 11:54 +0900, Itagaki Takahiro wrote:
> > Here is an update partitioning syntax patch.
> >
> > A bug reported by Marko is fixed.
>
> I will review and eventually commit this, if appropriate, though it is
> 3rd in my queu
Greg Smith wrote:
> I've marked Simon as the next reviewer and expected committer on this
> patch and have updated it to "Returned with Feedback".
OK. I'll re-submit improved patches in the next commit fest.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
--
Sent via pgsql-h
Simon Riggs wrote:
I will review and eventually commit this, if appropriate, though it is
3rd in my queue and will probably not be done for at least 2 weeks,
possibly 4 weeks.
I've marked Simon as the next reviewer and expected committer on this
patch and have updated it to "Returned with Fee
On Fri, 2009-12-04 at 11:54 +0900, Itagaki Takahiro wrote:
> Here is an update partitioning syntax patch.
>
> A bug reported by Marko is fixed.
I will review and eventually commit this, if appropriate, though it is
3rd in my queue and will probably not be done for at least 2 weeks,
possibly 4 wee
Emmanuel Cecchet wrote:
> Should we add the 'WITH (...) TABLESPACE tbs' options to the syntax
> since they are supported?
Added the description.
> Do we support ALTER ... SET TABLESPACE?
DROP/ALTER PARTITION are synonyms for DROP/ALTER TABLE.
SET TABLESPACE is also supported. Added the descr
Greg Smith wrote:
I just made a few updates to
http://wiki.postgresql.org/wiki/Table_partitioning , merging in the
stuff that had been on the ToDo page and expanding the links to
discussion on this list a bit. The number of submitted patches over
the last couple of years that handle some subs
I just made a few updates to
http://wiki.postgresql.org/wiki/Table_partitioning , merging in the
stuff that had been on the ToDo page and expanding the links to
discussion on this list a bit. The number of submitted patches over the
last couple of years that handle some subset of the desired f
Emmanuel Cecchet wrote:
> I think that other databases allows the
> user to define a tablespace for each partition in the create table
> statement.
WITH and TABLESPACE clause are supported for each partition.
=# CREATE TABLE parent (...) PARTITION BY (key)
(
PARTITION child_1 VALU
Hi,
Sorry for commenting only now but I think that we need to be able to
store the partitions in different tablespaces. Even if originally the
create table creates all partitions in the same tablespace, individual
partitions should be allowed to be moved in different tablespaces using
alter t
On Fri, Nov 20, 2009 at 2:08 AM, Simon Riggs wrote:
> On Thu, 2009-11-19 at 10:53 -0500, Robert Haas wrote:
>> On Thu, Nov 19, 2009 at 9:58 AM, Markus Wanner wrote:
>> > Hi,
>> >
>> > Robert Haas wrote:
>> >>
>> >> Settling on a syntax, and an internal representation for that syntax,
>> >
>> > I'
On Thu, 2009-11-19 at 10:53 -0500, Robert Haas wrote:
> On Thu, Nov 19, 2009 at 9:58 AM, Markus Wanner wrote:
> > Hi,
> >
> > Robert Haas wrote:
> >>
> >> Settling on a syntax, and an internal representation for that syntax,
> >
> > I've been under the impression that this was only about syntax. W
Peter Eisentraut writes:
> 2) I would prefer that you apply sizeof on the variable, not on the
> type. That way, the expression is independent of any type changes of
> the variable, and can be reviewed without having to scroll around for
> the variable definition.
FWIW, I think the general proje
Nikhil Sontakke writes:
>>> partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
>>
>> 1) Please stop casting the results of palloc and malloc. We are not
>> writing C++ here.
> I thought it was/is a good C programming practice to typecast (void *)
> always to the returning struc
On fre, 2009-11-20 at 11:14 +0530, Nikhil Sontakke wrote:
> Hi,
>
> >> > partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
> >
> > 1) Please stop casting the results of palloc and malloc. We are not
> > writing C++ here.
> >
>
> I thought it was/is a good C programming practice
Hi,
>> > partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
>
> 1) Please stop casting the results of palloc and malloc. We are not
> writing C++ here.
>
I thought it was/is a good C programming practice to typecast (void *)
always to the returning structure type!!
Regards,
Nik
On ons, 2009-11-18 at 13:52 +0900, Itagaki Takahiro wrote:
> > partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
>
> Oops, it should be "p"alloc. Thanks.
A very low-level comment:
1) Please stop casting the results of palloc and malloc. We are not
writing C++ here.
2) I would
On Thu, Nov 19, 2009 at 9:58 AM, Markus Wanner wrote:
> Hi,
>
> Robert Haas wrote:
>>
>> Settling on a syntax, and an internal representation for that syntax,
>
> I've been under the impression that this was only about syntax. What are the
> internal additions?
I haven't looked at it in detail, b
Hi,
Robert Haas wrote:
Settling on a syntax, and an internal representation for that syntax,
I've been under the impression that this was only about syntax. What are
the internal additions?
Generally speaking, I'd agree with Simon or even vote for doing the
internals first and add the synt
On Wed, 2009-11-18 at 13:24 +0900, Itagaki Takahiro wrote:
> Simon Riggs wrote:
>
> > Why not just wait until we have a whole patch and then apply?
>
> "A whole patch" can be written by many contributers instead of only
> one person, no? I think we need to split works for partitioning
> into se
Marko Tiikkaja wrote:
> this looks like a mistake:
> partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
Oops, it should be "p"alloc. Thanks.
> Maybe we should use something like
> PARTITION bar VALUES OPERATOR 0
> when the user specifies the operator?
I think we could have rea
Jaime Casanova wrote:
> > * If a table with the same name already exists when a partition
> > is created, the table is re-used as partition. This behavior
> > is required for pg_dump to be simple.
>
> i guess the table must be empty, if not we should be throw an error...
> and i actually pr
Simon Riggs wrote:
> Why not just wait until we have a whole patch and then apply?
"A whole patch" can be written by many contributers instead of only
one person, no? I think we need to split works for partitioning
into serveral parts to encourage developing it. I just did one of
the parts, "s
Marko Tiikkaja wrote:
> Jaime Casanova wrote:
> >> PARTITION name VALUES LESS THAN { range_upper | MAXVALUE }
> >>| PARTITION name VALUES IN ( list_value [,...] | DEFAULT )
> >
> > i remember someone making a comment about actually using operators
> > instead of LESS THEN and family
>
On Tue, Nov 17, 2009 at 4:31 PM, Simon Riggs wrote:
> On Thu, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
>
>> I think syntax support is a good start.
>
> I don't see a syntax-only patch as being any use at all to this
> community.
>
> We go to enormous lengths in other areas to never allow
On Thu, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
> I think syntax support is a good start.
I don't see a syntax-only patch as being any use at all to this
community.
We go to enormous lengths in other areas to never allow patches with
restrictions. Why would we allow a patch that is es
Jaime Casanova wrote:
* If a table with the same name already exists when a partition
is created, the table is re-used as partition. This behavior
is required for pg_dump to be simple.
i guess the table must be empty, if not we should be throw an error...
and i actually prefer some more
On Thu, Nov 12, 2009 at 5:54 AM, Itagaki Takahiro
wrote:
> I added psql and pg_dump support to Partitioning Syntax patch.
> Paritioning information can be retrieved with a new system function
> pg_get_partitiondef(parentRelid). Both psql and pg_dump use it.
>
i haven't seen the patch but:
>
> *
Hi,
I'm reviewing your patch. The patch applies without problems and the
feature works as advertised. I have yet to look at the code in detail,
but it looks sane and seems to work. However, this looks like a mistake:
partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo));
or am I
Hi,
>> Is this the same as / similar to Oracle's syntax?
>
> Yes.
>
>> IIRC Nikhil's patch was Oracle's syntax
>
> No. See:
> http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/statements_7002.htm#i2125922
>
Any decent prevalent partitioning syntax should be ok IMHO. IIRC,
MySQL parit
Devrim GNDZ wrote:
> Is this the same as / similar to Oracle's syntax?
Yes.
> IIRC Nikhil's patch was Oracle's syntax
No. See:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/statements_7002.htm#i2125922
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
--
Sen
Robert Haas writes:
> IMO, the real problem is that the type interface is poorly
> encapsulated. There's way too much code that knows about the internal
> details of a type - namely, that it's a 32-bit integer modified by a
> second 32-bit integer. I think there are still places where the code
>
On Fri, 2009-10-30 at 17:39 -0400, Robert Haas wrote:
> IMO, the real problem is that the type interface is poorly
> encapsulated. There's way too much code that knows about the internal
> details of a type - namely, that it's a 32-bit integer modified by a
> second 32-bit integer. I think there
On Fri, Oct 30, 2009 at 5:16 PM, Tom Lane wrote:
> Jeff Davis writes:
>> I haven't looked at all of these places yet, so maybe a few simple
>> changes would allow us to treat typmod as a full 32 bits. Or perhaps it
>> could just be expanded to a signed 64-bit int. What do you think?
>
> Neither i
Jeff Davis writes:
> I haven't looked at all of these places yet, so maybe a few simple
> changes would allow us to treat typmod as a full 32 bits. Or perhaps it
> could just be expanded to a signed 64-bit int. What do you think?
Neither is likely to happen, and even disregarding that, I doubt pe
* Jeff Davis (pg...@j-davis.com) wrote:
> Oid is unsigned, typmod is signed. We might be able to get away with it,
> but -1 is treated specially in some places outside of the type-specific
> functions, e.g. exprTypmod().
Any negative result returned from the input handling function is
considered a
On Fri, 2009-10-30 at 19:12 +0200, Heikki Linnakangas wrote:
> Wait, it doesn't? A typmod is a 32-bit integer, like Oids. Am I missing
> something?
Oid is unsigned, typmod is signed. We might be able to get away with it,
but -1 is treated specially in some places outside of the type-specific
funct
Jeff Davis wrote:
> On Fri, 2009-10-30 at 10:03 +0200, Peter Eisentraut wrote:
>> I can't help but wonder if the period type might better be a generic
>> container for pairs of scalar, totally-ordered types.
>
> That would be ideal. However, it doesn't really look like our type
> system was built
>> PARTITION BY RANGE ( a_expr )
>> ...
>> PARTITION BY HASH ( a_expr )
>> PARTITIONS num_partitions;
> Unless someone comes up with a maintenance plan for stable hashfunctions, we
> should probably not dare look into this yet.
What would cover the common use case of per-day quals and drops ove
On Fri, 2009-10-30 at 10:03 +0200, Peter Eisentraut wrote:
> I can't help but wonder if the period type might better be a generic
> container for pairs of scalar, totally-ordered types.
That would be ideal. However, it doesn't really look like our type
system was built to handle that kind of thing
On Thu, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
> I'd like to improve partitioning feature in 8.5.
Nice.
> Here is syntax I propose:
Is this the same as / similar to Oracle's syntax?
IIRC Nikhil's patch was Oracle's syntax, and I prefer having that one
instead of inventing our own
On Thu, 2009-10-29 at 15:19 -0700, Jeff Davis wrote:
> I can't help but wonder if the PERIOD type might be better for
> representing a partition range. It would make it easier to express and
> enforce the constraint that no two partition ranges overlap ;)
I can't help but wonder if the period type
Greg Stark wrote:
> >> * ALTER TABLE ... DROP [COLUMN] name [CASCADE | RESTRICT]
> >> * ALTER TABLE ... DROP PARTITION name [CASCADE | RESTRICT]
>
> Do we need a DROP PARTITION command at all? What would it even do?
Currently no. So, it would be good to treat PARTITION as
just a synonym of TA
On Thu, Oct 29, 2009 at 7:14 PM, Robert Haas wrote:
>> CREATE TABLE does not require PARTITION to be a reserved keyword,
>> but there are conflicts in ALTER TABLE ADD/DROP PARTITION:
>>
>> * ALTER TABLE ... DROP [COLUMN] name [CASCADE | RESTRICT]
>> * ALTER TABLE ... DROP PARTITION name [CASCAD
Peter Eisentraut wrote:
> On tor, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
> > Range partitioning:
> > CREATE TABLE table_name ( columns )
> > PARTITION BY RANGE ( a_expr )
> > (
> > PARTITION name VALUES LESS THAN [(] const [)],
> > PARTITION name VALUES LESS THA
On Thu, Oct 29, 2009 at 9:51 PM, Itagaki Takahiro
wrote:
>
> Heikki Linnakangas wrote:
>
>> > The keyword "PARTITION" is
>> > added to the full-reserved keyword list to support ADD/DROP PARTITION.
>>
>> Any chance to avoid that? PARTITION seems like something people might
>> well use as a column
Heikki Linnakangas wrote:
> > The keyword "PARTITION" is
> > added to the full-reserved keyword list to support ADD/DROP PARTITION.
>
> Any chance to avoid that? PARTITION seems like something people might
> well use as a column or variable name. OTOH, it is reserved in SQL2008
> and SQL2003.
On Fri, 2009-10-30 at 00:10 +0200, Peter Eisentraut wrote:
> On tor, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
> > Range partitioning:
> > CREATE TABLE table_name ( columns )
> > PARTITION BY RANGE ( a_expr )
> > (
> > PARTITION name VALUES LESS THAN [(] const [)],
> >
On tor, 2009-10-29 at 11:15 +0900, Itagaki Takahiro wrote:
> Range partitioning:
> CREATE TABLE table_name ( columns )
> PARTITION BY RANGE ( a_expr )
> (
> PARTITION name VALUES LESS THAN [(] const [)],
> PARTITION name VALUES LESS THAN [(] MAXVALUE [)] -- overflow partition
On Thursday 29 October 2009 18:33:22 Greg Stark wrote:
> On Thu, Oct 29, 2009 at 3:35 AM, Nikhil Sontakke
>
> wrote:
> > So +1 on solidifying the syntax first and then sorting out the other
> > minute, intricate details later..
>
> I like that idea as well but I have a concern. What will we do w
On Thu, Oct 29, 2009 at 3:35 AM, Nikhil Sontakke
wrote:
> So +1 on solidifying the syntax first and then sorting out the other
> minute, intricate details later..
I like that idea as well but I have a concern. What will we do with
pg_dump. If the PARTITION commands are just syntactic sugar for
cr
Itagaki Takahiro wrote:
> The keyword "PARTITION" is
> added to the full-reserved keyword list to support ADD/DROP PARTITION.
Any chance to avoid that? PARTITION seems like something people might
well use as a column or variable name. OTOH, it is reserved in SQL2008
and SQL2003.
--
Heikki Linn
On 29 Oct 2009, at 02:15, Itagaki Takahiro wrote:
I'd like to improve partitioning feature in 8.5.
Kedar-san's previous work is wonderful, but I cannot see any updated
patch.
http://archives.postgresql.org/message-id/bd8134a40906080702s96c90a9q3bbb581b9bd0d...@mail.gmail.com
So, I'll take o
Hi,
> So, I'll take over the work if there are no ones to do it.
> I'm thinking to add syntax support first. Table partitioning was
> proposed many times, but it is still not applied into core.
> The reason is it is too difficult to make perfect partitioning
> feature at once. I think syntax suppo
2009/10/29 Itagaki Takahiro :
> I'd like to improve partitioning feature in 8.5.
> Kedar-san's previous work is wonderful, but I cannot see any updated patch.
> http://archives.postgresql.org/message-id/bd8134a40906080702s96c90a9q3bbb581b9bd0d...@mail.gmail.com
>
> So, I'll take over the work if th
I'd like to improve partitioning feature in 8.5.
Kedar-san's previous work is wonderful, but I cannot see any updated patch.
http://archives.postgresql.org/message-id/bd8134a40906080702s96c90a9q3bbb581b9bd0d...@mail.gmail.com
So, I'll take over the work if there are no ones to do it.
I'm thinking
72 matches
Mail list logo
