2010/10/7 Simon Riggs :
> On Thu, 2010-10-07 at 14:10 +0200, Vincenzo Romano wrote:
>
>> Making these things sub-linear (whether not O(log n) or even O(1) ),
>> provided that there's way to, would make this RDBMS more appealing
>> to enterprises.
>> I mean also
2010/10/7 Simon Riggs :
> On Thu, 2010-10-07 at 14:10 +0200, Vincenzo Romano wrote:
>
>> Making these things sub-linear (whether not O(log n) or even O(1) ),
>> provided that there's way to, would make this RDBMS more appealing
>> to enterprises.
>> I mean also
2010/10/7 Stephen Frost :
> * Vincenzo Romano (vincenzo.rom...@notorand.it) wrote:
>> So, what'd be the right approach in your vision?
>
> Have you read http://wiki.postgresql.org/wiki/Table_partitioning and the
> various places it links to..?
>
>> I mean, if y
2010/10/7 Stephen Frost :
> * Vincenzo Romano (vincenzo.rom...@notorand.it) wrote:
>> I would expect a parser to ... ehm ... parse the CHECK constraint
>> expression at "CREATE TABLE " time and
>> extract all the needed "high quality metadata", like the li
2010/10/7 Stephen Frost :
> * Vincenzo Romano (vincenzo.rom...@notorand.it) wrote:
>> 2010/10/7 Stephen Frost :
>> > * Vincenzo Romano (vincenzo.rom...@notorand
.it) wrote:
>> > The problem is that CHECK conditions can contain just about anything,
>> > hence
2010/10/7 Stephen Frost :
> * Vincenzo Romano (vincenzo.rom...@notorand.it) wrote:
>> Which kind of information are you thinking about?
>> I think that the stuff you put into the CHECK condition for the table
>> will say it all.
>
> The problem is that CHECK condit
ble to.
But I need to understand things that are already known but I didn't know yet.
> --
> Álvaro Herrera
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Vincenzo Romano at NotOrAnd Information Technologie
2010/10/7 Greg Smith :
> Vincenzo Romano wrote:
>>
>> I see the main problem in the way the planner "understands" which
>> partition
>> is useful and which one is not.
>> Having the DDL supporting the feature could just be syntactic sugar
>> if t
2010/10/7 Stephen Frost :
> * Vincenzo Romano (vincenzo.rom...@notorand.it) wrote:
>> I see the main problem in the way the planner "understands" which partition
>> is useful and which one is not.
>> Having the DDL supporting the feature could just be syntactic sugar
rs of partitions as long as we have to resort to
> theorem-proving to lead us to the correct partition.
>
> regards, tom lane
>
I'm not sure about MySQL, but Oracle can handle large partitioning.
So I would say there's a way to achieve the same goal.
--
Vincenzo
some way off. If you're in a
> position to help with (or fund) the coding, it can be made to happen
> faster, of course.
This is why I was asking for directions: brwosing the whole code to look for the
relevant stuff is quite time consuming.
> --
> Robert Haas
> Enterp
50+ a year.
Is there any precise direction to where look into the code for it?
Is there a way to put this into a wish list?
--
Vincenzo Romano at NotOrAnd Information Technologies
Software Hardware Networking Training Support Security
--
NON QVIETIS MARIBVS NAVTA PERITVS
--
Sent via pgsql-hacker
Any feedbacks from TGL and Heikki, then?
2010/7/29 Joshua D. Drake :
> On Thu, 2010-07-29 at 19:52 +0200, Vincenzo Romano wrote:
>> 2010/7/29 Joshua D. Drake :
>> > On Thu, 2010-07-29 at 19:34 +0200, Vincenzo Romano wrote:
>> >
>> >> I expect that a more com
ke I need to go the hard way ...
Starting from postgresql-8.4.4/src/backend/optimizer
--
Vincenzo Romano at NotOrAnd Information Technologies
Software Hardware Networking Training Support Security
--
cel +393398083886 fix +390823454163 fax +3902700506964
gtalk. vincenzo.rom...@notorand.it skype. no
2010/7/30 Greg Stark :
> On Fri, Jul 30, 2010 at 11:24 AM, Vincenzo Romano
> wrote:
>> At a first glance it seems that for inheritance some bottleneck is
>> hindering a full exploit for table partitioning.
>
> There have been lengthy discussions of how to implement par
good insights about scalability.
At a first glance it seems that for inheritance some bottleneck is
hindering a full exploit for table partitioning.
Is there anyone who knows whether those algorithms are linear or not?
And of course, I agree that real tests on real data will provide the real
test.
Or maybe checking against the source code and its documentation, if any.
--
Vincenzo Romano at NotOrAnd Information Technologies
Software Hardware Networking Training Support Security
--
NON QVIETIS MARIBVS NAVTA PERITVS
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
2010/7/29 Joshua D. Drake :
> On Thu, 2010-07-29 at 19:34 +0200, Vincenzo Romano wrote:
>
>> I expect that a more complex schema will imply higher workloads
>> on the query planner. What I don't know is how the increase in the
>> workload will happen: linearly, subl
2010/7/29 Joshua D. Drake :
> On Thu, 2010-07-29 at 19:08 +0200, Vincenzo Romano wrote:
>> Hi all.
>> I'm wondering about PGSQL scalability.
>> In particular I have two main topics in my mind:
>>
>> 1. What'd be the behavior of the query planner in
ection algorithms in these two cases that
would kill my design.
Is there any insight about these two points?
--
NotOrAnd Information Technologies
Vincenzo Romano
--
NON QVIETIS MARIBVS NAVTA PERITVS
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
simpler and enough
>
> Pavel
I do like the printf-like approach more than my proposal!
Do you think about a built-in implementation rather than the on in PLGSQL?
--
Vincenzo Romano
NotOrAnd Information Technologies
NON QVIETIS MARIBVS NAVTA PERITVS
--
Sent via pgsql-hackers
e composite and
> nested values are significant break.
>
> see in archive
> http://archives.postgresql.org/pgsql-patches/2006-08/msg00267.php
>
> Regards
> Pavel Stehule
>
>
> 2010/1/14 Vincenzo Romano :
>> Hi all.
>> There's currently a limitation
e the responsibility to the programmer to ensure whether
the dynamic command makes any syntactic and semantic sense.
--
Vincenzo Romano
NotOrAnd Information Technologies
NON QVIETIS MARIBVS NAVTA PERITVS
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
23 matches
Mail list logo
