Re: [HACKERS] [GENERAL] INHERITS and planning

2005-06-16 Thread Tom Lane
Simon Riggs <[EMAIL PROTECTED]> writes: > 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. Just FYI, the proposed fix is already in, and I think it's a net w

Re: [HACKERS] [GENERAL] INHERITS and planning

2005-06-16 Thread Simon Riggs
On Thu, 2005-06-16 at 00:55 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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

Re: [HACKERS] [GENERAL] INHERITS and planning

2005-06-16 Thread Simon Riggs
On Thu, 2005-06-16 at 12:59 +0800, Christopher Kings-Lynne wrote: > > 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

Re: [HACKERS] [GENERAL] INHERITS and planning

2005-06-15 Thread Simon Riggs
On Thu, 2005-06-16 at 01:10 -0400, Greg Stark wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > > If you really do need that many, you can go to the trouble of grouping > > them in two levels of nesting, so you have a root table, multiple month > > tables and then each month table with multiple

Re: [HACKERS] [GENERAL] INHERITS and planning

2005-06-15 Thread Greg Stark
Simon Riggs <[EMAIL PROTECTED]> writes: > If you really do need that many, you can go to the trouble of grouping > them in two levels of nesting, so you have a root table, multiple month > tables and then each month table with multiple day tables (etc). I wonder if testing deeply nested inherita

Re: [HACKERS] [GENERAL] INHERITS and planning

2005-06-15 Thread Christopher Kings-Lynne
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

Re: [HACKERS] [GENERAL] INHERITS and planning

2005-06-15 Thread Tom Lane
Simon Riggs <[EMAIL PROTECTED]> 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,

Re: [HACKERS] [GENERAL] INHERITS and planning

2005-06-15 Thread Simon Riggs
On Fri, 2005-06-10 at 02:10 -0400, Tom Lane wrote: > What I see in the profile is > > % cumulative self self total > time seconds secondscalls s/call s/call name > 42.04 15.5815.58 9214 0.00 0.00 list_nth_cell > 20.29 2

Re: [HACKERS] [GENERAL] INHERITS and planning

2005-06-09 Thread Tom Lane
Edmund Dengler <[EMAIL PROTECTED]> writes: > Is there an issue when a large number of INHERITS tables exist for > planning? Well, there are a number of issues whenever a single query references a whole lot of tables in any fashion. It's only with Neil Conway's rewrite of the List package in 8.0 t