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
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
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
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
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
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:
> 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,
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
On Thu, 2005-06-09 at 21:30 -0400, Edmund Dengler wrote:
> We have 2 base tables, and use INHERITS to partition the data. When we get
> around 2000-2200 sub-tables (approx 1000-1100 per base table), planning a
> SELECT statement on the base table (ie, to search all sub-tables) will
> start slowing
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
Greetings!
Is there an issue when a large number of INHERITS tables exist for
planning?
We have 2 base tables, and use INHERITS to partition the data. When we get
around 2000-2200 sub-tables (approx 1000-1100 per base table), planning a
SELECT statement on the base table (ie, to search all sub-ta
11 matches
Mail list logo
