Re: [HACKERS] INHERITS and planning

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] INHERITS and planning
Дата
Msg-id 10517.1118897705@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] INHERITS and planning  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: [HACKERS] INHERITS and planning  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Re: [HACKERS] INHERITS and planning  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-general
Simon Riggs <simon@2ndquadrant.com> writes:
> Looks bad... but how does it look for 1000 inherited relations? My
> feeling is that we should not be optimizing the case above 1000
> relations. That many partitions is very unwieldy.

Well, it's not so much that I care about queries with 1000+ relations,
as that this is a good way to stress-test the code and find out where
the performance issues are.  There are many thousand lines of code that
can never be performance-sensitive, but to expose the ones that are
it helps to push the envelope a bit.

Until Neil fixed the list.c package in 8.0, we had pretty much zero
chance of avoiding O(N^2) or worse behavior on almost any measure of
query size N that you cared to name; because most of the internal data
structures depend on lists.  (You do know that Postgres was once written
in Lisp, right?)  Now that that basic issue is taken care of, it's worth
looking at secondary bad behaviors ... I've been doing some hacking in
this area lately, but it's not all fixed yet.

            regards, tom lane

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

Предыдущее
От: Jamie Deppeler
Дата:
Сообщение: Executing SQL Script
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: [HACKERS] INHERITS and planning