[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] re: optimizations for inheritance searching

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] re: optimizations for inheritance searching
Date: Sun, 12 Mar 2006 17:03:54 +0100
User-agent: Mutt/1.5.11+cvs20060126

On Sun, Mar 12, 2006 at 02:08:27PM +0800, Syan Tan wrote:

> if they fix the postgresql planner, then you can revert to the original sql,
> which is more terse .
> Stephen Friedrich <s.friedrich AT>
> 18 Jan 2006 13:41:24
> Another restriction:
> Even if you do define indexes on the inherited tables yourself, often they
> won't be used if you query the parent table.
> Even when constraint exclusion restricts the query to a single inherited 
> table,
> it seems that postgres always tries to merge result rows from the parent table
> (even if it is empty) and the inherited table.
> For example even if both the parent and an inherited table defined an index 
> for
> column "id", then a query on the parent table that includes "order by id" does
> _not_ use the indexes, but a costly sort is done after combining the rows from
> the inherited table and the zero rows from the parent table.
> So performance can be drastically worse if you use partitions.
> I think it applies to inheritance in general as well as for partitioning.

We have already proven this guy wrong. Even if this guy *is*
right, currently, and the planner "forgets" to look at the
possibility of index scans despite it being possible we
should then keep the original, terse sql and use "set
enable_seqscan to off" right before it in the same
transaction to stay as close as possible to how we would
want things to be would the work properly.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]