On Scalability
in [PgSql]
|
Prev: Obtain a University Degree based on your professional experience for a more satisfactory life. admonishing akenes aglycone
Next: [HACKERS] review patch: Distinguish between unique indexes and unique constraints
From: Vincenzo Romano on 29 Jul 2010 13:52 2010/7/29 Joshua D. Drake <jd(a)commandprompt.com>: > On Thu, 2010-07-29 at 19:34 +0200, Vincenzo Romano wrote: > >> I expect that a more complex schema will imply higher workloads >> on the query planner. What I don't know is how the increase in the >> workload will happen: linearly, sublinearly, polynomially or what? Do you think I should ask somewhere else? Any hint? >> Thanks anyway for the insights, Joshua. >> Does the 60-100 tables limit applies to a single level >> of inheritance? Or is it more general? > > I do not currently have experience (except that it is possible) with > multi-level inheritance and postgresql. Thanks anyway. -- Vincenzo Romano at NotOrAnd Information Technologies Software Hardware Networking Training Support Security -- NON QVIETIS MARIBVS NAVTA PERITVS -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Joshua D. Drake" on 29 Jul 2010 14:16 On Thu, 2010-07-29 at 19:52 +0200, Vincenzo Romano wrote: > 2010/7/29 Joshua D. Drake <jd(a)commandprompt.com>: > > On Thu, 2010-07-29 at 19:34 +0200, Vincenzo Romano wrote: > > > >> I expect that a more complex schema will imply higher workloads > >> on the query planner. What I don't know is how the increase in the > >> workload will happen: linearly, sublinearly, polynomially or what? > > Do you think I should ask somewhere else? > Any hint? The two people that would likely know the best are on vacation, TGL and Heikki. You may have to wait a bit. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 29 Jul 2010 16:09 > Do you think I should ask somewhere else? > Any hint? I might suggest asking on the pgsql-performance mailing list instead. You'll get *lots* more speculation there. However, the only way you're really going to know is to test. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Vincenzo Romano on 29 Jul 2010 17:30 2010/7/29 Josh Berkus <josh(a)agliodbs.com>: > >> Do you think I should ask somewhere else? >> Any hint? > > I might suggest asking on the pgsql-performance mailing list instead. > You'll get *lots* more speculation there. However, the only way you're > really going to know is to test. Or maybe checking against the source code and its documentation, if any. -- Vincenzo Romano at NotOrAnd Information Technologies Software Hardware Networking Training Support Security -- NON QVIETIS MARIBVS NAVTA PERITVS -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Vincenzo Romano on 29 Jul 2010 13:34
2010/7/29 Joshua D. Drake <jd(a)commandprompt.com>: > On Thu, 2010-07-29 at 19:08 +0200, Vincenzo Romano wrote: >> Hi all. >> I'm wondering about PGSQL scalability. >> In particular I have two main topics in my mind: >> >> 1. What'd be the behavior of the query planner in the case I have >> a single huge table with hundreds or thousands of partial indexes >> (just differing by the WHERE clause). >> This is an idea of mine to make index-partitioning instead of >> table-partitioning. > > Well the planner is not going to care about the partial indexes that > don't match the where clause but what you are suggesting is going to > make writes and maintenance extremely expensive. It will also increase > planning time as the optimizer at a minimum has to discard the use of > those indexes. > >> >> 2. What'd be the behavior of the query planner in the case I have >> hundreds or thousands of child tables, possibly in a multilevel hierarchy >> (let's say, partitioning by year, month and company). > > Again, test it. Generally speaking the number of child tables directly > correlates to planning time. Most experience that 60-100 tables is > really the highest you can go. > > It all depends on actual implementation and business requirements > however. > > Sincerely, > > Joshua D. Drake I expect that a more complex schema will imply higher workloads on the query planner. What I don't know is how the increase in the workload will happen: linearly, sublinearly, polinomially or what? Significant testing would require a prototype implementation with an almost complete feed of data from the current solution. But I'm at the feasibility study stage and have not enough resources for that. Thanks anyway for the insights, Joshua. Does the 60-100 tables limit applies to a single level of inheritance? Or is it more general? -- NotOrAnd Information Technologies Vincenzo Romano -- NON QVIETIS MARIBVS NAVTA PERITVS -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |