From: | Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | PostgreSQL Hackers and Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: On Scalability |
Date: | 2010-07-30 10:24:10 |
Message-ID: | AANLkTinamvPzbsLM3p9du3K8Xpqo1XCK7aA3vzAKifRX@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
2010/7/29 Josh Berkus <josh(at)agliodbs(dot)com>:
>
>> Or maybe checking against the source code and its documentation, if any.
>
> No, not really. What you really want to know is: what's the real
> planner overhead of having dozens/hundreds of partial indexes? What's
> the write overhead? There's no way you can derive that from the source
> code faster than you can test it.
Again, as the test would be rather killing for my group at this stage.
I think that knowing whether certain parts have been implemented
with linear or sub-linear (or whatever else) algorithms would
give 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 thing.
--
Vincenzo Romano at NotOrAnd Information Technologies
Software Hardware Networking Training Support Security
--
NON QVIETIS MARIBVS NAVTA PERITVS
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2010-07-30 10:49:37 | Re: On Scalability |
Previous Message | Pavel Stehule | 2010-07-30 09:56:53 | Re: patch (for 9.1) string functions ( correct patch attached ) |
From | Date | Subject | |
---|---|---|---|
Next Message | Alban Hertroys | 2010-07-30 10:48:31 | Re: How to improve: performance of query on postgresql 8.3 takes days |
Previous Message | A. Kretschmer | 2010-07-30 06:11:29 | Re: How to improve: performance of query on postgresql 8.3 takes days |