agora inbox for postgres@postgres.berkeley.edu  

help / color / mirror / Atom feed

From: Joe Hellerstein <jmh@cs.berkeley.edu>
To: Jeff Sidell <jsidell@postgres.Berkeley.EDU>
Cc: POSTGRES database manager <postgres@postgres.Berkeley.EDU>
Subject: Re: b-tree bug?
Date: Wed, 01 May 1996 11:22:00 -0700
Message-ID: <199605011822.LAA03301@matador.CS.Berkeley.EDU> (raw)
In-Reply-To: <199605011816.LAA01344@parkcity.CS.Berkeley.EDU>

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

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: postgres@postgres.berkeley.edu
  Cc: jmh@cs.berkeley.edu, jsidell@postgres.Berkeley.EDU
  Subject: Re: b-tree bug?
  In-Reply-To: <199605011822.LAA03301@matador.CS.Berkeley.EDU>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox