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
bra
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
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 wan
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 in
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;
>
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 b
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
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 o
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 ha
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
> sale
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 real
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 views/q
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 map
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
com
14 matches
Mail list logo
