út 25. 8. 2020 v 9:32 odesílatel Pavel Stehule <pavel.steh...@gmail.com> napsal:
> > > po 24. 8. 2020 v 21:43 odesílatel Pavel Stehule <pavel.steh...@gmail.com> > napsal: > >> >> >> ne 23. 8. 2020 v 23:08 odesílatel Tom Lane <t...@sss.pgh.pa.us> napsal: >> >>> Pavel Stehule <pavel.steh...@gmail.com> writes: >>> > I am sending a patch that is years used in GoodData. >>> >>> I'm quite unexcited about that. I'd be the first to agree that the >>> ten-pages estimate is a hack, but it's not an improvement to ask users >>> to think of a better value ... especially not as a one-size-fits- >>> all-relations GUC setting. >>> >> >> This patch is just a workaround that works well 10 years (but for one >> special use case) - nothing more. Without this patch that application >> cannot work ever. >> >> >>> I did have an idea that I think is better than my previous one: >>> rather than lying about the value of relpages, let's represent the >>> case where we don't know the tuple density by setting reltuples = -1 >>> initially. This leads to a patch that's a good bit more invasive than >>> the quick-hack solution, but I think it's a lot cleaner on the whole. >>> >> >>> A possible objection is that this changes the FDW API slightly, as >>> GetForeignRelSize callbacks now need to deal with rel->tuples possibly >>> being -1. We could avoid an API break if we made plancat.c clamp >>> that value to zero; but then FDWs still couldn't tell the difference >>> between the "empty" and "never analyzed" cases, and I think this is >>> just as much of an issue for them as for the core code. >>> >> >>> I'll add this to the upcoming CF. >>> >> >> I'll check it >> > > I think it can work. It is a good enough solution for people who need a > different behaviour with minimal impact on people who don't need a change. > all tests passed I'll mark this patch as ready for commit Regards Pavel > Regards > > Pavel > > >> >> Regards >> >> Pavel >> >>> >>> regards, tom lane >>> >>>
