On Mon, Mar 17, 2003 at 11:23:47AM -0600, Taral wrote:
> Yes, that's exactly it. It's an index _scan_. It should simply be able
> to read the maximum straight from the btree.
Still doesn't work, even with rewritten query. It sort a
Limit(Sort(Index Scan)), with 1333 rows being pulled from the inde
On Mon, Mar 17, 2003 at 11:23:47 -0600,
Taral <[EMAIL PROTECTED]> wrote:
> On Sat, Mar 15, 2003 at 09:23:28AM -0600, Bruno Wolff III wrote:
> > On Fri, Mar 14, 2003 at 14:19:46 -0600,
> > Taral <[EMAIL PROTECTED]> wrote:
> > > Same setup, different query:
> > >
> > > test=> explain select max(
On Sat, Mar 15, 2003 at 09:23:28AM -0600, Bruno Wolff III wrote:
> On Fri, Mar 14, 2003 at 14:19:46 -0600,
> Taral <[EMAIL PROTECTED]> wrote:
> > Same setup, different query:
> >
> > test=> explain select max(time) from test where id = '1';
> > NOTICE: QUERY PLAN:
> >
> > Aggregate (cost=5084
On Fri, Mar 14, 2003 at 14:19:46 -0600,
Taral <[EMAIL PROTECTED]> wrote:
> Same setup, different query:
>
> test=> explain select max(time) from test where id = '1';
> NOTICE: QUERY PLAN:
>
> Aggregate (cost=5084.67..5084.67 rows=1 width=0)
> -> Index Scan using idx on test (cost=0.00..50
On Fri, Mar 14, 2003 at 10:43:30PM -0500, Tom Lane wrote:
> Sure. That's why we have a planner that distinguishes between startup
> cost and total cost, and interpolates when a LIMIT is involved. But
> if this mergesort idea only helps for small-limit cases, that's another
> restriction on its sc
Taral <[EMAIL PROTECTED]> writes:
> On Thu, Mar 13, 2003 at 10:30:27PM -0500, Tom Lane wrote:
>> The idea is you look at the index to make a list of main-table tuple
>> positions you are interested in, which you represent compactly as a
>> compressed bitmap. [snip]
> And it loses bigtime in the c
Same setup, different query:
test=> explain select max(time) from test where id = '1';
NOTICE: QUERY PLAN:
Aggregate (cost=5084.67..5084.67 rows=1 width=0)
-> Index Scan using idx on test (cost=0.00..5081.33 rows=1333 width=0)
Since the index is (id, time), why isn't the index being used t
On Thu, Mar 13, 2003 at 10:30:27PM -0500, Tom Lane wrote:
> The idea is you look at the index to make a list of main-table tuple
> positions you are interested in, which you represent compactly as a
> compressed bitmap. (There is some finagling needed because PG actually
> uses block/line number r
Taral <[EMAIL PROTECTED]> writes:
> On Thu, Mar 13, 2003 at 04:28:34PM -0500, Tom Lane wrote:
>> Seems like a waste of effort to me. I find this example less than
>> compelling --- the case that could be sped up is quite narrow,
>> and the potential performance gain not all that large. (A sort
>>
On Thu, Mar 13, 2003 at 04:28:34PM -0500, Tom Lane wrote:
> Seems like a waste of effort to me. I find this example less than
> compelling --- the case that could be sped up is quite narrow,
> and the potential performance gain not all that large. (A sort
> is a sort however you slice it, with O(
Taral <[EMAIL PROTECTED]> writes:
> Do I need to code merge sort into postgresql?
Seems like a waste of effort to me. I find this example less than
compelling --- the case that could be sped up is quite narrow,
and the potential performance gain not all that large. (A sort
is a sort however you
I tried general, but no response. Anyone here can shed some light on the
issue? Do I need to code merge sort into postgresql?
- Forwarded message from Taral <[EMAIL PROTECTED]> -
From: Taral <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Wed, 12 Mar 2003 17:54:35 -0600
Subject: [GENERAL]
12 matches
Mail list logo
