Re: ORDER BY and LIMIT not propagated on inherited

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Matteo Beccati <php(at)beccati(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: ORDER BY and LIMIT not propagated on inherited
Date: 2005-09-02 12:35:32
Message-ID: 1125664532.3956.278.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, 2005-09-02 at 12:20 +0200, Matteo Beccati wrote:

> I'm using inherited tables to partition some data which can grow very
> large. Recently I discovered that a simple query that on a regular table
> would use an index was instead using seq scans (70s vs a guessed 2s).
> The well known query is:
>
> SELECT foo FROM bar ORDER BY foo DESC LIMIT 1
>
> (The same applies for SELECT MIN(foo) FROM bar using 8.1)
>
>
> The query plan generated when running the query on a table which has
> inheritance forces the planner to choose a seq_scan for each table.
> Wouldn't be a good thing to also promote ORDER BYs and LIMITs to each
> subscan (like WHERE does)?

The tuple_fraction implied by LIMIT is already passed through to each
child table when using an inherited table structure. This would then be
taken into account when plans are made for each child table. I don't
think the situation you observe occurs as a result of query planning.

Do your child tables have indexes on them? Indexes are not inherited
onto child tables, so it is possible that there is no index for the
planner to elect to use.

Best Regards, Simon Riggs

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Matteo Beccati 2005-09-02 12:54:39 Re: ORDER BY and LIMIT not propagated on inherited
Previous Message Arnau 2005-09-02 11:43:05 Advise about how to delete entries