Subject: Re: b-tree bug?

From: Joe Hellerstein <[email-masked]>
Date: Wed, 01 May 1996 10:15:07 -0700

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.

Joe

-------------------------------------
Joseph M. Hellerstein
EECS Computer Science Division
University of California, Berkeley
http://www.cs.berkeley.edu/~jmh

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

---

From: Jeff Sidell <[email-masked]>
Date: Wed, 1 May 1996 11:16:15 -0700 (PDT)

> 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

---

From: Joe Hellerstein <[email-masked]>
Date: Wed, 01 May 1996 11:22:00 -0700

> that they are retrieving different numbers of tuples. 

I believe you're right that there's a bug.

> *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