Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
I've been hacking on the idea of an Append node which maintains the ordering
of its subtables merging their records in order.
I finally got round to looking at this ...
A lot of things to chew on. Thanks very much.
Gregory Stark [EMAIL PROTECTED] writes:
I've been hacking on the idea of an Append node which maintains the ordering
of its subtables merging their records in order.
I finally got round to looking at this ...
1) I still haven't completely figured out what to do with equivalence classes.
Hello Gregory,
Gregory Stark wrote:
It is kind of like a merge join but not quite. It's interleaving rows rather
than matching them up. It's more like the final merge of a sort which also
uses a heap to efficiently find the next value from the source tapes.
Well, maybe my point here is: why
* Markus Schiltknecht:
uses a heap to efficiently find the next value from the source tapes.
Well, maybe my point here is: why do you need the heap to sort?
I think you need it because there are potentially many input types.
--
Florian Weimer[EMAIL PROTECTED]
BFK
Hi,
Florian Weimer wrote:
Florian Weimer wrote:
I think you need it because there are potentially many input types.
Eh, tapes.
Aha..
Given the partitioning case, I'd expect all rows to have an equal
tuple descriptor. Maybe this is a matter of what to optimize, then?
Could you elaborate
* Markus Schiltknecht:
You need a priority queue to figure out from which tape (partition)
you need to remove the next tuple.
And why do you need lots of heap memory to do that? Anything wrong
with the zipper approach I've outlined upthread?
heap == priority queue here, I guess. Looking at
Heikki Linnakangas [EMAIL PROTECTED] writes:
Markus Schiltknecht wrote:
Florian Weimer wrote:
Given the partitioning case, I'd expect all rows to have an equal
tuple descriptor. Maybe this is a matter of what to optimize, then?
Could you elaborate on what use case you have in mind?
You
Gregory Stark [EMAIL PROTECTED] writes:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Markus Schiltknecht wrote:
And why do you need lots of heap memory to do that? Anything wrong with the
zipper approach I've outlined upthread?
We're talking about a binary heap, with just one node per
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gregory Stark wrote:
But that requires a) dealing with the problem of the parent table which has no
constraints and b) an efficient way to prove that constraints don't overlap
and order them properly. The latter looks like an O(n^2) problem to me,
Gregory Stark wrote:
Ideally we would also be able to do this in the planner. If the planner could
determine from the constraints that all the key values from each partition are
non-overlapping and order them properly then it could generate a regular
append node with a path order without the
On Fri, 2007-11-23 at 12:36 +, Gregory Stark wrote:
I also did an optimization similar to the bounded-sort case where we check if
the next tuple from the same input which last contributed the result record
comes before the top element of the heap. That avoids having to do an insert
and
Hi,
Florian Weimer wrote:
I think you need it because there are potentially many input types.
Given the partitioning case, I'd expect all rows to have an equal tuple
descriptor. Maybe this is a matter of what to optimize, then?
Could you elaborate on what use case you have in mind?
Markus Schiltknecht wrote:
Florian Weimer wrote:
Given the partitioning case, I'd expect all rows to have an equal
tuple descriptor. Maybe this is a matter of what to optimize, then?
Could you elaborate on what use case you have in mind?
You need a priority queue to figure out from which
* Markus Schiltknecht:
Florian Weimer wrote:
I think you need it because there are potentially many input types.
Eh, tapes.
Given the partitioning case, I'd expect all rows to have an equal
tuple descriptor. Maybe this is a matter of what to optimize, then?
Could you elaborate on what use
But that requires a) dealing with the problem of the parent table
which has no
constraints and ...
Imho we should provide a mechanism that forces the parent to be empty
and let the planner know.
e.g. a false constraint on parent ONLY.
Andreas
---(end of
Gregory Stark wrote:
Not quite the same since the Executor-based implementation would have a static
tree structure based on the partitions. Even if the partitions are all empty
except for one or two you would still have to push the result records through
all the nodes for the empty partitions.
Hi,
Heikki Linnakangas wrote:
AFAICT it's roughly the same data structure as the zipper tree you
envisioned, but not implemented with separate executor nodes for each
level.
Aha, that sounds good to me. ;-)
As I've already mentioned, I think it's even better to simply show the
user a
I've been hacking on the idea of an Append node which maintains the ordering
of its subtables merging their records in order. This is important for
partitioned tables since otherwise a lot of plans are not available such as
merge joins.
The logic I've followed is to do as follows:
1) Go through
Hello Gregory,
Gregory Stark wrote:
I've been hacking on the idea of an Append node which maintains the ordering
of its subtables merging their records in order. This is important for
partitioned tables since otherwise a lot of plans are not available such as
merge joins.
Cool!
Some time
Markus Schiltknecht [EMAIL PROTECTED] writes:
1) Go through all subrels asking for any interesting pathkey lists. Gather up
the union of all of these.
I also tried to modify the Append node first, then figured that it might be
better to base on the merge join node instead. While this
20 matches
Mail list logo
