On Thu, 2005-06-16 at 00:55 -0400, Tom Lane wrote:
> Simon Riggs <simon@xxxxxxxxxxxxxxx> 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.
I very much agree and I also appreciate you taking the time to look into
this since it clearly has an effect on the usefulness of partitioning. I
wanted to give my opinion that more than 1000 is not a frequent use
case.
> 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.
Yes, know about that; I agree with the general principles you discuss.
Your suggested fix to the 2000+ inherited relation problem seemed like
it would apply to an area that most people would never use, yet would
have an effect on anybody using LockAcquire. IMHO that is not worth the
effort or risk, and that is from somebody that you know has been
involved in tracking down O(N^2) behaviour in other parts of the code.
Best Regards, Simon Riggs
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
