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.
On 5/16/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> regression=# explain analyze select * from tenk1 where unique1 between 100
> and 1000;
> QUERY PLAN
> --
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
> >
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.
"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 ha
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.
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.
>
> T
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().
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
obvi
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 s
"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 sti
11 matches
Mail list logo
