Skip site navigation (1) Skip section navigation (2)

Re: On Scalability

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL Hackers and Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: On Scalability
Date: 2010-07-30 10:49:37
Message-ID: AANLkTinsLzK=zNXYXokhTrEATDv7eJmPb_OkWy838nh0@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
On Fri, Jul 30, 2010 at 11:24 AM, Vincenzo Romano
<vincenzo(dot)romano(at)notorand(dot)it> 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 partitioning
to fix these precise problems, yes.


> Is there anyone who knows whether those algorithms are linear or not?

They're linear in both cases. But they happen at plan time rather than
query execution time. So if your application prepares all its queries
and then uses them many times it would not slow down query execution
but would slow down the query planning time. In some applications this
is much better but in others unpredictable run-times is as bad as long
run-times.

Also in the case of having many partial indexes it would slow down
inserts and updates as well, though to a lesser degree, and that would
happen at execution time.


-- 
greg

In response to

Responses

pgsql-performance by date

Next:From: Vincenzo RomanoDate: 2010-07-30 11:40:31
Subject: Re: On Scalability
Previous:From: Alban HertroysDate: 2010-07-30 10:48:31
Subject: Re: How to improve: performance of query on postgresql 8.3 takes days

pgsql-hackers by date

Next:From: Jan UrbaƄskiDate: 2010-07-30 11:02:32
Subject: Re: TwoPO: experimental join order algorithm
Previous:From: Vincenzo RomanoDate: 2010-07-30 10:24:10
Subject: Re: On Scalability

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group