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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Urbański | 2010-07-30 11:02:32 | Re: TwoPO: experimental join order algorithm |
Previous Message | Vincenzo Romano | 2010-07-30 10:24:10 | Re: On Scalability |
From | Date | Subject | |
---|---|---|---|
Next Message | Vincenzo Romano | 2010-07-30 11:40:31 | Re: On Scalability |
Previous Message | Alban Hertroys | 2010-07-30 10:48:31 | Re: How to improve: performance of query on postgresql 8.3 takes days |