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 LAA24866 for postgres-redist; Wed, 1 May 1996 11:22:03 -0700 Resent-From: POSTGRES mailing list Resent-Message-Id: <199605011822.LAA24866@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 matador.CS.Berkeley.EDU (matador.CS.Berkeley.EDU [128.32.35.135]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with ESMTP id LAA24816; Wed, 1 May 1996 11:22:02 -0700 Received: from matador.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by matador.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id LAA03301; Wed, 1 May 1996 11:22:01 -0700 From: Joe Hellerstein Message-Id: <199605011822.LAA03301@matador.CS.Berkeley.EDU> To: Jeff Sidell cc: postgres@postgres.Berkeley.EDU (POSTGRES database manager) Subject: Re: b-tree bug? In-reply-to: Your message of "Wed, 01 May 1996 11:16:15 PDT." <199605011816.LAA01344@parkcity.CS.Berkeley.EDU> Date: Wed, 01 May 1996 11:22:00 -0700 Resent-To: postgres-redist@postgres.Berkeley.EDU Resent-Date: Wed, 01 May 96 11:22:03 -0700 Resent-XMts: smtp > 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. I believe you're right that there's a bug. > > 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". Actually, the last time I checked the number of duplicate values returned by postgres queries was officially non-deterministic (this was Postquel semantics). For example, if the plan was sorting/hashing/index-probing anyway it could remove dups, but if it wasn't it could leave them there for efficiency. An unhappy corrolary to this semantics is that two identical tuples may or may not get treated separately in an aggregate, and you're not supposed to care. In point of fact, I doubt this is what's going on in your example, but it's just possible. And one of my pet peeves. Joe ============================================================================== 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/