Tom Lane wrote:
Jeffrey W. Baker [EMAIL PROTECTED] writes:
I see that Tom has already done the infrastructure work by adding
getmulti, but getmulti isn't used by nodeIndexscan.c, only
nodeBitmapIndexscan.c. Will btree index scans be executed by creating
in-memory bitmaps in 8.1, or will some
Jeffrey Baker wrote:
Would you take a patch that retained the optimized executions of plans
returning 1 tuple and also fixed the random heap problem?
Can you elaborate on what you're proposing? Obviously sorted b+-tree
output is important for a lot more than just min()/max(). I don't see an
Neil Conway wrote:
Jeffrey Baker wrote:
Would you take a patch that retained the optimized executions of plans
returning 1 tuple and also fixed the random heap problem?
Can you elaborate on what you're proposing? Obviously sorted b+-tree
output is important for a lot more than just min()/max().
On Mon, 2005-05-16 at 09:53 -0400, Tom Lane wrote:
Jeffrey Baker [EMAIL PROTECTED] writes:
Change the planner/executor to use the bitmap scan in all cases where
index order is unimportant. From my reading of the current code, the
bitmap scan is only used in case of a join.
This is a
On P, 2005-05-15 at 23:58 -0700, Jeffrey Baker wrote:
I'm considering one of the following courses of action:
Change nodeIndexscan.c to call index_getmulti, and to handle multiple
tuples returned. That code would sort the tuple array and store the
tuples in the result in disk order.
Jeffrey W. Baker [EMAIL PROTECTED] writes:
On Mon, 2005-05-16 at 09:53 -0400, Tom Lane wrote:
This is a fallacy, and I think your concern is largely mistaken. Have
you experimented with the cases you are worried about?
Perhaps I have not stated the problem clearly. Believe me, I have
On Mon, 2005-05-16 at 14:35 -0400, Tom Lane wrote:
Jeffrey W. Baker [EMAIL PROTECTED] writes:
It's also possible that changing the btree scan to work in
groups of tuples instead of single tuples would make more sense, which
is why I ventured two different solution to the problem.
My
Tom Lane [EMAIL PROTECTED] writes:
Jeffrey W. Baker [EMAIL PROTECTED] writes:
I see that Tom has already done the infrastructure work by adding
getmulti, but getmulti isn't used by nodeIndexscan.c, only
nodeBitmapIndexscan.c. Will btree index scans be executed by creating
in-memory
On 5/16/05, Tom Lane [EMAIL PROTECTED] wrote:
regression=# explain analyze select * from tenk1 where unique1 between 100
and 1000;
QUERY PLAN
Jeffrey Baker [EMAIL PROTECTED] writes:
Change the planner/executor to use the bitmap scan in all cases where
index order is unimportant. From my reading of the current code, the
bitmap scan is only used in case of a join.
This is a fallacy, and I think your concern is largely mistaken.
About this time last year I was holding forth on the value of visiting
the heap in TID order, even when index scan tuples are randomly ordered.
Today I decided to start working on the problem stated in this TODO
item:
Fetch heap pages matching index entries in sequential order
Jeffrey W. Baker [EMAIL PROTECTED] writes:
I see that Tom has already done the infrastructure work by adding
getmulti, but getmulti isn't used by nodeIndexscan.c, only
nodeBitmapIndexscan.c. Will btree index scans be executed by creating
in-memory bitmaps in 8.1, or will some scans still be
12 matches
Mail list logo
