Re: On Scalability

From: Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it>
To: Greg Stark <gsstark(at)mit(dot)edu>
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 11:40:31
Message-ID: AANLkTimzC+zNvfXK5X9y2LimQV6bwH91F0hrGPN18v_K@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

2010/7/30 Greg Stark <gsstark(at)mit(dot)edu>:
> 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.

Any reference?

>> 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.

Hmmm ... maybe I'm missing the inner meaning of your remarks, Greg.
By using PREPARE I run the query planned sooner and I should use
the plan with the later execution.
You can bet that some of the PREPAREd query variables will
pertain to either the child table's CHECK contraints (for table partitions)
or to the partial index's WHERE condition (for index partitioning).

It's exactly this point (execution time) where the "linearity" will
kill the query
over a largely partitioned table.

Is this what you meant? :-)

> 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.

This makes fully sense to me.

--
Vincenzo Romano at NotOrAnd Information Technologies
Software Hardware Networking Training Support Security
--
NON QVIETIS MARIBVS NAVTA PERITVS

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mike Fowler 2010-07-30 11:50:25 Re: review: xml_is_well_formed
Previous Message Robert Haas 2010-07-30 11:22:51 Re: reducing NUMERIC size for 9.1

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2010-07-30 14:03:52 Re: Questions on query planner, join types, and work_mem
Previous Message Greg Stark 2010-07-30 10:49:37 Re: On Scalability