On T, 2005-05-10 at 23:09 +0100, Simon Riggs wrote:
> On Tue, 2005-05-10 at 16:31 +0300, Hannu Krosing wrote:
> > > If all partitions in the query had identical indexes on them, then we
> > > have another option. In that case, each index could be thought to form
> > > part of a larger index ordere
On Tue, 2005-05-10 at 15:01 -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Tue, May 10, 2005 at 12:16:17AM +0100, Simon Riggs wrote:
> >> On Mon, 2005-05-09 at 18:53 -0400, Tom Lane wrote:
> >>> I disagree. The code is there, it could use work, and what you are
> >>> ba
On Tue, 2005-05-10 at 16:44 +0300, Hannu Krosing wrote:
> On T, 2005-05-10 at 16:31 +0300, Hannu Krosing wrote:
> > On E, 2005-05-09 at 23:30 +0100, Simon Riggs wrote:
>
> > There are 2 possibly expensive steps:
> >
> > 1. the conversion to "AND'ed list of simple clauses" (unknown
> > complexity
On Tue, 2005-05-10 at 16:31 +0300, Hannu Krosing wrote:
> On E, 2005-05-09 at 23:30 +0100, Simon Riggs wrote:
> > ISTM fairly straightforward to produce a similar "static" plan along the
> > same lines, using Result nodes to implement Partition Elimination.
> >
> > Append
> > Result
> > SeqS
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Tue, May 10, 2005 at 12:16:17AM +0100, Simon Riggs wrote:
>> On Mon, 2005-05-09 at 18:53 -0400, Tom Lane wrote:
>>> I disagree. The code is there, it could use work, and what you are
>>> basically proposing is to duplicate both the existing work and
On Tue, May 10, 2005 at 12:16:17AM +0100, Simon Riggs wrote:
> On Mon, 2005-05-09 at 18:53 -0400, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > 1. Embellish inheritance or separate infrastructure?
> >
> > > It seems prudent to avoid building on that foundation, even though we
>
On T, 2005-05-10 at 16:31 +0300, Hannu Krosing wrote:
> On E, 2005-05-09 at 23:30 +0100, Simon Riggs wrote:
> There are 2 possibly expensive steps:
>
> 1. the conversion to "AND'ed list of simple clauses" (unknown
> complexity)
>
> 2. matching each of "simple" clauses in the and list with all
On E, 2005-05-09 at 23:30 +0100, Simon Riggs wrote:
> A more in-depth consideration of the major design options and trade-offs
> available to us... this is an internals related discussion.
>
> Comments?
>
> 1. Embellish inheritance or separate infrastructure?
>
> Inheritance is a somewhat strang
Tom Lane <[EMAIL PROTECTED]> writes:
> > Partition Elimination relies upon being able to prove at execution time
>
> You mean plan time.
Fwiw, both are possible.
In oracle there are (at least) three different cases:
1. For queries like "select * from tab" the plan shows a multiple partition
sc
On Mon, 2005-05-09 at 18:53 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > 1. Embellish inheritance or separate infrastructure?
>
> > It seems prudent to avoid building on that foundation, even though we
> > may decide to use some similar approaches.
>
> I disagree. The cod
Simon Riggs <[EMAIL PROTECTED]> writes:
> 1. Embellish inheritance or separate infrastructure?
> It seems prudent to avoid building on that foundation, even though we
> may decide to use some similar approaches.
I disagree. The code is there, it could use work, and what you are
basically proposi
A more in-depth consideration of the major design options and trade-offs
available to us... this is an internals related discussion.
Comments?
1. Embellish inheritance or separate infrastructure?
Inheritance is a somewhat strange PostgreSQL feature, with a few
gotchas. The "big one" is the lack
Many people have been discussing Table Partitioning lately. I've also
been giving thought to how to implement Table Partitioning within
PostgreSQL, as part of the Bizgres project for Business Intelligence.
After some discussion on Bizgres, I've now posted the most important and
common Use Cases f
13 matches
Mail list logo
