Re: PATCH: use foreign keys to improve join estimates v1

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: PATCH: use foreign keys to improve join estimates v1
Дата
Msg-id CANP8+j+BVL-VisDjzQACgK-csxPX5aX7SKH-GS6R1y5g+2txTQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PATCH: use foreign keys to improve join estimates v1  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: PATCH: use foreign keys to improve join estimates v1  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On 3 April 2016 at 22:09, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
On 04/03/2016 10:06 PM, Simon Riggs wrote:
On 14 March 2016 at 19:42, Tomas Vondra <tomas.vondra@2ndquadrant.com
<mailto:tomas.vondra@2ndquadrant.com>> wrote:

...


I'd like to split this into 2 patches
1) Add FK info to relcache
2) use FK info in planner

Would the credit for this be 1) Tomas, 2) Tomas + David ?

I could split the patch like that, but I don't quite see the point. The two parts will not overlap at all, so not making reviews any simpler. So the only reason for such split seems to be be different credits, but would we actually commit the pieces independently? Not sure about that.

Oh sorry. Reason for split was because adding the FK info to relcache was a very solid addition, whereas we might imagine some churn around the planner aspects.

I'd be inclined to see a little more explanatory docs on this.

That's probably a good idea. Do you have any particular place for the docs in mind?

Detailed comments in the planner part of the patch. The discussion around this patch isn't reflected enough in the patch.

Have we done any tests on planning overhead for cases where multiple
FKs exist?


I have done some benchmarks initially, and haven't measured any noticeable impact. But the code changed since than, so I'll redo that and post some results.

Thanks 

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby
Следующее
От: Alex Shulgin
Дата:
Сообщение: Re: More stable query plans via more predictable column statistics