From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Rohit Gaddi <rohitgaddi(at)yahoo(dot)co(dot)in> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: query plan ignoring check constraints |
Date: | 2005-06-20 17:35:24 |
Message-ID: | 200506201035.24406.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Rohit,
> Now, when I do a select on the basetable with a range of ids, it looks up
> each subtable that inherits from the base table and using an indexed scan
> searches for values in the range. It does it even for subtables whose check
> constraint completely rules out the possibility of it containing any such
> row . Should not check constraint act as the first filter? The index should
> ideally be scanned only when the check constraint is passed by the search
> criteria but surprisingly it did not happen. The explain analyze showed
> cost for index scans of subtables that cannot contain rows matching the
> search criteria.
This is called "range partitioning". We're working on it. You're welcome to
join the Bizgres project where most of the discussion on this feature takes
place:
www.bizgres.org
http://pgfoundry.org/mail/?group_id=1000107
--
Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2005-06-20 18:20:54 | Re: buildfarm notifications |
Previous Message | Lee Harr | 2005-06-20 17:23:18 | Re: plpgsql constraint checked data fails to restore |