Simon Riggs wrote:
in those cases you are really just maintaining the indexes for partitioning
purposes. On older data it may be desirable not to have lots of indexes,
or at least use their resources on the indexes they really do want.
Also, if you have a List partitioned table where all rows
On Sun, 2005-07-24 at 06:44 -0700, Ron Mayer wrote:
Simon Riggs wrote:
in those cases you are really just maintaining the indexes for partitioning
purposes. On older data it may be desirable not to have lots of indexes,
or at least use their resources on the indexes they really do want.
Tom Lane [EMAIL PROTECTED] writes:
Uh, maybe you have sql_inheritance turned off? Every version I can
remember would show you a pretty explicit Append plan for inheritance
scans...
staging= show sql_inheritance;
sql_inheritance
-
on
(1 row)
Maybe I'm doing something more
On Sun, 2005-07-24 at 15:00 -0400, Greg Stark wrote:
Maybe I'm doing something more obvious wrong?
db= create table _test (a integer);
CREATE TABLE
db= create table _test2 (like _test);
CREATE TABLE
Yes, unfortunately. You need the phrase INHERITS (_test) after the
bracket and
On Fri, 2005-07-22 at 18:32 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
In summary, the CE feature will be a huge performance gain for
qualifying queries against large tables in PostgreSQL databases.
BTW, before we spend too much time chasing an emperor that may have no
Simon Riggs [EMAIL PROTECTED] writes:
It's very common to scan whole ranges of dates on a large table, so in
those cases you are really just maintaining the indexes for partitioning
purposes. On older data it may be desirable not to have lots of indexes,
or at least use their resources on the
Greg Stark [EMAIL PROTECTED] writes:
Note also that the index is only useful if the index is *being used*. And
index scans are much slower than sequential scans.
You miss my point entirely: an indexscan that hasn't got to retrieve any
rows (because it has a constraint that points off the end of
Tom Lane [EMAIL PROTECTED] writes:
And this decision is made separately for each child table, so the fact that
a seqscan might be the best bet for the target partition doesn't stop the
planner from using the indexscan in other partitions.
That was the detail I was missing. I'm surprised
Greg Stark [EMAIL PROTECTED] writes:
That was the detail I was missing. I'm surprised because I actually tested
this before I sent the message and saw a plan like this with a single
sequential scan node despite the three child tables:
staging= explain select * from _test where a=1;
Simon Riggs [EMAIL PROTECTED] writes:
In summary, the CE feature will be a huge performance gain for
qualifying queries against large tables in PostgreSQL databases.
BTW, before we spend too much time chasing an emperor that may have no
clothes, it's worth asking whether this feature is really
Tom,
On 7/22/05 3:32 PM, Tom Lane [EMAIL PROTECTED] wrote:
but the scan all rows will only happen if no index is provided on
DateKey in the child tables. Otherwise the planner will probably
select plans like this:
- Index Scan using i1 on sales_jan_dateitemoutlet
A Guide to the Constraint Exclusion Feature
===
Simon Riggs 2ndQuadrant [EMAIL PROTECTED]
INTRODUCTION
Constraint Exclusion (CE) is an optimizer patch submitted for PostgreSQL
8.1. CE aims to greatly improve the performance for certain types of
Sounds very useful - even for my small systems. Does it/would it work on
an ordinary table (for those cases currently using UNION ALL)?
--
Richard Huxton
Archonet Ltd
---(end of broadcast)---
TIP 5: don't forget to increase your free space
On Wed, 2005-07-13 at 14:02 +0100, Richard Huxton wrote:
Sounds very useful - even for my small systems. Does it/would it work on
an ordinary table (for those cases currently using UNION ALL)?
I'm looking into that aspect right now.
I see no reason why it shouldn't work for UNION ALL
14 matches
Mail list logo
