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.
Firstly we
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
need
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).
Ü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 we
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
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
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
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 which are
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
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, then, so as not
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 database which
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 constraints,
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
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
than
you
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
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
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
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 separate from
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
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 it was
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
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 operator,
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
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
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,
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
partitioning
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
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
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
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
partitioning which is grammar based. This grammar was developed by Jeff
Cohen at
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[,
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')
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 that
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
partitioning which
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've proposed an
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, 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
38 matches
Mail list logo
