Re: [HACKERS] INHERITS and planning - Mailing list pgsql-general

From Tom Lane
Subject Re: [HACKERS] INHERITS and planning
Date
Msg-id 10517.1118897705@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] INHERITS and planning  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [HACKERS] INHERITS and planning
Re: [HACKERS] INHERITS and planning
List 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 by date:

Previous
From: Jamie Deppeler
Date:
Subject: Executing SQL Script
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: [HACKERS] INHERITS and planning