Return-Path: owner-postman
Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id LAA24688 for postgres-redist; Wed, 1 May 1996 11:16:19 -0700
Resent-From: POSTGRES mailing list <postman@postgres.Berkeley.EDU>
Resent-Message-Id: <199605011816.LAA24688@nobozo.CS.Berkeley.EDU>
X-Authentication-Warning: nobozo.CS.Berkeley.EDU: Host localhost.Berkeley.EDU didn't use HELO protocol
Sender: owner-postman@postgres.Berkeley.EDU
X-Return-Path: owner-postman
Received: from parkcity.CS.Berkeley.EDU (parkcity.CS.Berkeley.EDU [128.32.37.61]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with ESMTP id LAA24695 for <postgres>; Wed, 1 May 1996 11:16:18 -0700
Received: (jsidell@localhost) by parkcity.CS.Berkeley.EDU (8.6.10/8.6.3) id LAA01344; Wed, 1 May 1996 11:16:16 -0700
From: Jeff Sidell <jsidell@postgres.Berkeley.EDU>
Message-Id: <199605011816.LAA01344@parkcity.CS.Berkeley.EDU>
Subject: Re: b-tree bug?
To: jmh@cs.berkeley.edu (Joe Hellerstein)
Date: Wed, 1 May 1996 11:16:15 -0700 (PDT)
Cc: postgres@postgres.Berkeley.EDU (POSTGRES database manager)
In-Reply-To: <2.2.32.19960501171507.0091ee60@postgres.berkeley.edu> from "Joe Hellerstein" at May 1, 96 10:15:07 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1047      
Resent-To: postgres-redist@postgres.Berkeley.EDU
Resent-Date: Wed, 01 May 96 11:16:19 -0700
Resent-XMts: smtp

> 
> Well, last time I checked, postgres officially assigned no semantics to
> duplicates, so it's *just* possible that everything officially is working
> "right" in your example, because postgres aggregates are semantically
> meaningless in the face of duplicates.  But that's probably not what's going on.
> 

I'm not sure what the official semantics for aggregates/aggregates-over-
duplicates are, but unless I'm missing something, there's a bug:
The aggregate node takes tuples passed in to it from the subplan
and calls the appropriate function for each such tuple.  Count() simply
adds one to a running count.  The fact that we're getting different
counts for an underlying index scan and a sequential scan indicates
that they are retrieving different numbers of tuples. 

Semantically, "select count(*) from LINEITEM where L_SHIPDATE >= D1
and L_SHIPDATE < D2" means "Tell me how many tuples in the LINEITEM
table have a shipdate D such that D1 <= D <= D2".  Not "how many
*unique* tuples" or "how many tuples with unique shipdates".

Jeff

==============================================================================
   To add/remove yourself to/from the POSTGRES mailing list: send mail with 
   the subject line ADD or DEL to "postgres-request@postgres.Berkeley.EDU".
   If this fails, send mail to "post_questions@postgres.Berkeley.EDU" and
   a human will deal with it.  DO NOT post to the "postgres" mailing list.
==============================================================================
              URL: http://s2k-ftp.CS.Berkeley.EDU:8000/postgres/