[Jeff Sidell <jsidell@postgres.Berkeley.EDU>]

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