Re: On Scalability - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: On Scalability
Date
Msg-id 4CADA271020000250003662A@gw.wicourts.gov
Whole thread Raw
In response to Re: On Scalability  (Vincenzo Romano <vincenzo.romano@notorand.it>)
Responses Re: On Scalability
List pgsql-hackers
Vincenzo Romano <vincenzo.romano@notorand.it> wrote:
> 2010/10/7 Stephen Frost <sfrost@snowman.net>:
>> Yes, that would be the problem.  Proving something based on
>> expressions is alot more time consuming and complicated than
>> being explicitly told what goes where.
> 
> Consuming computing resources at DDL-time should be OK if that
> will lead to big savings at DML-time (run-time), my opinion. It'd
> be just like compile time optimizations.
I think something you haven't entirely grasped is how pluggable
PostgreSQL is -- you can not only define your own functions in a
wide variety of languages (including C), but your own data types,
operators, casts, index strategies, etc.  Determining, even at DDL
time that even a built-in datatype's expression is or isn't useful
in partitioning could be quite painful in the absence of syntax
specifically geared toward partitioning.  If there's a CHECK
constraint on a polygon column to ensure that it isn't a concave
polygon, you might be facing a lot of work to know whether it's
involved in partitioning.  Now imagine that a CHECK constraint is on
a column with a user defined type and uses the @%!! operator and
that the user has changed some of the allowed implicit casts used in
the expression.
While this flexibility is a great strength of PostgreSQL, it makes
some things more difficult to implement than they would be in more
limited database products.
-Kevin


pgsql-hackers by date:

Previous
From: Vincenzo Romano
Date:
Subject: Re: On Scalability
Next
From: Stephen Frost
Date:
Subject: Re: On Scalability