Re: On Scalability

From: Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: On Scalability
Date: 2010-10-07 14:20:25
Message-ID: AANLkTikgdbUbNgR8f82CqPmnRK+LD4J-=OxaeHVY4+Od@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

2010/10/7 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> On 07.10.2010 10:41, Simon Riggs wrote:
>>> Constraint exclusion is linear with respect to number of partitions.
>>> Why do you say exponential?
>
>> For some reason I thought the planner needs to check the constraints of
>> the partitions against each other, but you're right, clearly that's not
>> the case. Linear it is.
>
> Well, it's really more like O(mn) where m is the number of partitions
> and n is the number of clauses in the query --- and not only that, but
> the O() notation is hiding a depressingly high constant factor.  And
> then there are practical problems like failing to exclude partitions as
> soon as there are any parameters in the query.

Does the same considerations apply to partial indexes?
I mean, I can replace table partitioning with index partitioning concept.
(Well I know it's not really the same).
Would then it be the same O(nm) to let the planner choose the right indexes
given a certain query?

> There's basically no way that we're going to get decent performance for
> large numbers 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 Romano at NotOrAnd Information Technologies
Software Hardware Networking Training Support Security
--
cel +393398083886 fix +390823454163 fax +3902700506964
gtalk. vincenzo(dot)romano(at)notorand(dot)it skype. notorand.it
--
NON QVIETIS MARIBVS NAVTA PERITVS

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Aidan Van Dyk 2010-10-07 14:26:10 Re: Issues with Quorum Commit
Previous Message Magnus Hagander 2010-10-07 14:11:00 Re: Git cvsserver serious issue

Browse pgsql-performance by date

  From Date Subject
Next Message Stephen Frost 2010-10-07 14:29:27 Re: On Scalability
Previous Message Vincenzo Romano 2010-10-07 13:57:04 Re: On Scalability