On Tue, 2008-01-15 at 17:12 +, Gregory Stark wrote:
> > Wouldn't Segment Exclusion (maybe together with a specialized form of
> > CLUSTERing) handle that case much better than partitioning? Without the
> > need to
> > name all those thousands of partitions and manage them manually.
>
> First
On Mon, Jan 14, 2008 at 10:45:28PM -0500, Tom Lane wrote:
> Jeff Cohen <[EMAIL PROTECTED]> writes:
> > In the proposed solution, hash and list partitions work for all types
> > that support an equality operator, and range partitions work for all
> > types that support fully-ordered comparison.
> > Personally I find the automatic partition idea intriguing, where you
> > only have to choose an expression that equates to one value (value
> > group) per partition (and possibly a way to derive a
> partition name).
>
> IMO, better go right to a fully automated approach. Or why would you
>
"Markus Schiltknecht" <[EMAIL PROTECTED]> writes:
> Hi,
>
> Gregory Stark wrote:
>> In a previous life I had a database which had daily partitions. I assure you
>> it was unquestionably the right decision. Each day's data wasn't just
>> distinguished by the timestamp but actually was entirely sepa
Hi,
(sorry for the previous one, if delivered, that went of too early...)
Zeugswetter Andreas ADI SD wrote:
Yes, but the problem with the timestamp partitioned tables is, that the
window is sliding. Thus you would need two alter tables for each new
period. One that changes the constraint + one
Hi,
Zeugswetter Andreas ADI SD wrote:
Yes, but the problem with the timestamp partitioned tables is, that the
window is sliding. Thus you would need two alter tables for each new
period. One that changes the constraint + one that creates the new
partition. So it seems natural to join the two con
Hi,
Tom Lane wrote:
DBAs tend to be belt *and* suspenders guys, no?
I rather know those admins with stupid looking faces who are wondering
why their transactions fail. Often enough, that can have a lot of
different reasons. Extending the set of possible traps doesn't seem like
a clever idea
> > I don't agree with that at all. I can imagine plenty of situations
> > where a tuple falling outside the range of available partitions
*should*
> > be treated as an error. For instance, consider timestamped
observations
> > --- data in the future is certainly bogus, and data further back
tha
Hi,
Gregory Stark wrote:
In a previous life I had a database which had daily partitions. I assure you
it was unquestionably the right decision. Each day's data wasn't just
distinguished by the timestamp but actually was entirely separate from the
previous day's data. Both the archiving strategy
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't agree with that at all. I can imagine plenty of situations
>> where a tuple falling outside the range of available partitions *should*
>> be treated as an error.
> Isn't it better to have these constraints as table const
On Tue, Jan 15, 2008 at 10:36:17AM -0500, Tom Lane wrote:
> Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> > Jeff Cohen wrote:
> >> If you don't define a "default" partition to handle outliers, the
> >> insert should fail with an error.
>
> > IMO, you should always have a "default" partition,
"Markus Schiltknecht" <[EMAIL PROTECTED]> writes:
> Hi,
>
> Hans-Juergen Schoenig wrote:
>>> What do you need so many partitions for?
>>
>> having so many tables is not funny but it can be the only reasonable choice.
>
> Well, what do you do with all those partitions?
In a previous life I had a
Hi,
Tom Lane wrote:
I don't agree with that at all. I can imagine plenty of situations
where a tuple falling outside the range of available partitions *should*
be treated as an error. For instance, consider timestamped observations
--- data in the future is certainly bogus, and data further ba
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> Jeff Cohen wrote:
>> If you don't define a "default" partition to handle outliers, the
>> insert should fail with an error.
> IMO, you should always have a "default" partition, then, so as not to
> violate the constraints (by rejecting tuples wh
Hi,
Hans-Juergen Schoenig wrote:
What do you need so many partitions for?
having so many tables is not funny but it can be the only reasonable choice.
Well, what do you do with all those partitions? Most of them will end up
on the same storage subsystem. So, if you don't partition to spread
sure, but this can become really tedious for 1024 partitions,
Well, managing 1024 partitions manually is a tedious job, no matter
what grammar you take: You'll have to deal with 1024 different
partition names.
What do you need so many partitions for?
imagine a structure which is pa
Hi,
Hannu Krosing wrote:
I guess it would go to some "default" partition ?
Which doesn't have a name so far, which prevents from addressing that
partition. Nor is it pretty well defined, it's just a rest.
sure, but this can become really tedious for 1024 partitions,
Well, managing 1024 p
Ühel kenal päeval, E, 2008-01-14 kell 10:49, kirjutas Markus
Schiltknecht:
> Hi,
>
> Jeff Cohen wrote:
> > We did look at allowing general functions for partitioning and this was
> > one concern. The other is that we want to enforce that a row only gets
> > inserted into a single partition, so
Hi Jeff,
Jeff Cohen wrote:
If you don't define a "default" partition to handle outliers, the
insert should fail with an error.
IMO, you should always have a "default" partition, then, so as not to
violate the constraints (by rejecting tuples which are correct according
to the constraints).
Jeff Cohen <[EMAIL PROTECTED]> writes:
> In the proposed solution, hash and list partitions work for all types
> that support an equality operator, and range partitions work for all
> types that support fully-ordered comparison.
Surely a hashing method would require a *hashable* equality opera
On Jan 12, 2008, at 9:34 AM, Peter Eisentraut wrote:
Well, with an extensible system such as PostgreSQL you will need to
have a
partitioning scheme that can deal with extensions. Perhaps people
want to
partition by XML, GIS, text-search data, or whatever someone might
come up
with in the
On Jan 14, 2008, at 1:49 AM, Markus Schiltknecht wrote:
I don't think the separation into list, hash and range partitioning
is adequate. What is the system supposed to do, if you try to
insert a row which doesn't fit any of the values in your list or
doesn't fit any of the ranges you defin
On Sat, Jan 12, 2008 at 04:01:19PM +0530, NikhilS wrote:
> Hi,
>
> > We did look at allowing general functions for partitioning and this
> > was one concern. The other is that we want to enforce that a row
> > only gets inserted into a single partition, so we wanted a
> > declarative syntax where
Hi,
Jeff Cohen wrote:
We did look at allowing general functions for partitioning and this was
one concern. The other is that we want to enforce that a row only gets
inserted into a single partition, so we wanted a declarative syntax
where it was relatively easy to check that range and list sp
On Sat, Jan 12, 2008 at 05:47:30PM +, Simon Riggs wrote:
> On Sat, 2008-01-12 at 01:59 +0100, Gavin Sherry wrote:
> > The syntax is half the problem, performance is the other.
>
> The syntax looks great to me, but I think it is about 5% of the problem,
> maybe less. I don't really have any que
On Sat, 2008-01-12 at 01:59 +0100, Gavin Sherry wrote:
> The syntax is half the problem, performance is the other.
The syntax looks great to me, but I think it is about 5% of the problem,
maybe less. I don't really have any questions about the syntax, but I
may have thoughts when the implementatio
Jeff Cohen wrote:
> In order to make such error checking
> feasible, we would have to restrict the set of predicates you can use
> in the WHERE clause, so it wouldn't be completely general anyway.
Well, with an extensible system such as PostgreSQL you will need to have a
partitioning scheme that
Hi,
On Jan 12, 2008 6:29 AM, Gavin Sherry <[EMAIL PROTECTED]> wrote:
>
>
> The syntax is half the problem, performance is the other. I will bring
> the performance issues up in another thread. Yes, we are confident that
> we can address the performance issues that rule out the existing
> partit
Hi,
> We did look at allowing general functions for partitioning and this
> was one concern. The other is that we want to enforce that a row
> only gets inserted into a single partition, so we wanted a
> declarative syntax where it was relatively easy to check that range
> and list specifications
Hi,
> I've proposed an alternative approach, which we've called declarative
> partitioning which is grammar based. This grammar was developed by Jeff
> Cohen at Greenplum with some assistance from myself. It is to be
> completely open source.
>
<..>
FWIW, I had done some very initial work on decl
On Jan 11, 2008, at 4:03 PM, Mike wrote:
Pardon my ignorance as I've never actually used partitioning before
but
plan to in the near future, but couldn't the grammar resemble a common
WHERE clause more closely?
Hi Mike,
Thanks for your suggestions. The current syntax we chose is similar
On Fri, Jan 11, 2008 at 07:46:36PM -0500, Merlin Moncure wrote:
> On Jan 11, 2008 6:19 PM, Gavin Sherry <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > Many of you will have read the dynamic partitioning thread here:
> >
> > http://archives.postgresql.org/pgsql-hackers/2008-01/msg00028.php
> >
> > I
On Jan 11, 2008 6:19 PM, Gavin Sherry <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Many of you will have read the dynamic partitioning thread here:
>
> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00028.php
>
> I've proposed an alternative approach, which we've called declarative
> partition
On Jan 11, 2008, at 4:16 PM, Warren Turkal wrote:
On Jan 11, 2008 3:42 PM, Ron Mayer <[EMAIL PROTECTED]>
wrote:
What would be the drawbacks of
CREATE TABLE tablename(...)
PARTITION BY function_taking_row_returning_partition_name
instead of the explicit types?
Would that still allow the
On Jan 11, 2008 3:42 PM, Ron Mayer <[EMAIL PROTECTED]> wrote:
> What would be the drawbacks of
> CREATE TABLE tablename(...)
> PARTITION BY function_taking_row_returning_partition_name
> instead of the explicit types?
Would that still allow the optimizer to work as well as it could? It
seems t
Pardon my ignorance as I've never actually used partitioning before but
plan to in the near future, but couldn't the grammar resemble a common
WHERE clause more closely?
> ... PARTITION BY RANGE(order_date)
> (
> START (date '2005-12-01') end (date '2007-12-01')
>
Gavin Sherry wrote:
> CREATE TABLE is modified to accept a PARTITION BY clause. This clause
> contains one or more partition declarations. The syntax is as follows:
> PARTITION BY {partition_type} (column_name[, column_name...])
> [PARTITIONS number]
> (
>partition_declaration[, partition
37 matches
Mail list logo
