út 9. 10. 2018 v 16:13 odesílatel Pavel Stehule <pavel.steh...@gmail.com> napsal:
> > > út 9. 10. 2018 v 15:59 odesílatel Dmitry Dolgov <9erthali...@gmail.com> > napsal: > >> > On Tue, 9 Oct 2018 at 15:43, Pavel Stehule <pavel.steh...@gmail.com> >> wrote: >> > >> > Hi >> > >> > I tested last patch and I have some notes: >> > >> > 1. >> > >> > postgres=# explain select distinct a10000 from foo; >> > >> +-------------------------------------------------------------------------------------------+ >> > | QUERY PLAN >> | >> > >> +-------------------------------------------------------------------------------------------+ >> > | Unique (cost=0.43..4367.56 rows=9983 width=4) >> | >> > | -> Index Skip Scan using foo_a10000_idx on foo >> (cost=0.43..4342.60 rows=9983 width=4) | >> > >> +-------------------------------------------------------------------------------------------+ >> > (2 rows) >> > >> > In this case Unique node is useless and can be removed >> >> Just to clarify which exactly version were you testing? If >> index-skip-fallback.patch, >> then the Unique node was added there to address the situation when >> ndistinct is underestimated, with an idea to fallback to original plan >> (and to tolerate that I suggested to use Unique, since we don't know >> if fallback will happen or not during the planning). >> > > I tested index-skip-fallback.patch. > > It looks like good idea, but then the node should be named "index scan" > and other info can be displayed in detail parts. It can be similar like > "sort". > > The combination of unique and index skip scan looks strange :) > maybe we don't need special index skip scan node - maybe possibility to return unique values from index scan node can be good enough - some like "distinct index scan" - and the implementation there can be dynamic -skip scan, classic index scan, "index skip scan" is not good name if the implementaion is dynamic. > >> > 2. Can be nice COUNT(DISTINCT support) similarly like MIN, MAX suppport >> >> Yep, as far as I understand MIN/MAX is going to be the next step after >> this >> patch will be accepted. >> > > ok > > Now, the development cycle is starting - maybe it can use same > infrastructure like MIN/MAX and this part can be short. > > more if you use dynamic index scan > > >> > 3. Once time patched postgres crashed, but I am not able to reproduce >> it. >> >> Maybe you have at least some ideas what could cause that or what's the >> possible >> way to reproduce that doesn't work anymore? >> > > I think it was query like > > select count(*) from (select distinct x from tab) s > > >
