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 day
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 never
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's not so
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 win
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 23.10
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,
as
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
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 inheritance
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 that
