Re: BUG #13908: Query returns too few rows
От | David G. Johnston |
---|---|
Тема | Re: BUG #13908: Query returns too few rows |
Дата | |
Msg-id | CAKFQuwY6nzq9j9FDKL5zp5SgX5Z0S11y1Ado8yQcHWHEy4QLPQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #13908: Query returns too few rows (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #13908: Query returns too few rows
|
Список | pgsql-bugs |
On Tue, Feb 2, 2016 at 3:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > seth-p@outlook.com writes: > > Query (A-D) (with DISTINCT) should not return more rows than query (A) > (the > > identical query without DISTINCT), so clearly something is wrong there. > > That does seem fishy, but unless you can provide a self-contained test > case, it's unlikely that we are going to be able to magically locate > the problem. I'd suggest seeing if you can reproduce the issue with > some obfuscated or randomly-generated data. > =E2=80=8BWhile Tom is correct I'd like to make a couple of points... It apparently isn't the DISTINCT query that is increasing the count of rows but rather than the non-DISTINCT version fails to return/count as many as are actually present - but only when dealing with the entire range... =E2=80=8BLacking a reproducible test case you really need to at least suppl= y an EXPLAIN ANALYZE so that actual row counts at each node can be observed. The note about the apparent extra HASH first made me think that there must be some kind of hash collision involved in the data - apparently one that occurs between data points in B and C but not within B or within C...but I fear this might be a red herring. But if it is a collision then the odds of random data exhibiting the problem are quite slim... David J.
В списке pgsql-bugs по дате отправления: