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 ordered
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
scan.
2.
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 strange
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 others
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
may decide
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 much
of the
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
SeqScan
Result
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)
2.
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
basically proposing
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
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
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 proposing
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 code is there,
13 matches
Mail list logo
