Re: Any better plan for this query?..
От | Dimitri |
---|---|
Тема | Re: Any better plan for this query?.. |
Дата | |
Msg-id | 5482c80a0905120822t1a6c5d12y62d9002f4cd76ddf@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Any better plan for this query?.. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Any better plan for this query?..
("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: Any better plan for this query?.. ("Joshua D. Drake" <jd@commandprompt.com>) Re: Any better plan for this query?.. (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-performance |
Robert, what I'm testing now is 256 users max. The workload is growing progressively from 1, 2, 4, 8 ... to 256 users. Of course the Max throughput is reached on the number of users equal to 2 * number of cores, but what's important for me here - database should continue to keep the workload! - response time regressing, but the troughput should remain near the same. So, do I really need a pooler to keep 256 users working?? - I don't think so, but please, correct me. BTW, I did not look to put PostgreSQL in bad conditions - the test is the test, and as I said 2 years ago PostgreSQL outperformed MySQL on the same test case, and there was nothing done within MySQL code to improve it explicitly for db_STRESS.. And I'm staying pretty honest when I'm testing something. Rgds, -Dimitri On 5/12/09, Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, May 12, 2009 at 8:59 AM, Dimitri <dimitrik.fr@gmail.com> wrote: >> Wait wait, currently I'm playing the "stress scenario", so there are >> only 256 sessions max, but thing time is zero (full stress). Scenario >> with 1600 users is to test how database is solid just to keep a huge >> amount of users, but doing only one transaction per second (very low >> global TPS comparing to what database is able to do, but it's testing >> how well its internals working to manage the user sessions). > > Didn't we beat this to death in mid-March on this very same list? > Last time I think it was Jignesh Shah. AIUI, it's a well-known fact > that PostgreSQL doesn't do very well at this kind of workload unless > you use a connection pooler. > > *goes and checks the archives* Sure enough, 116 emails under the > subject line "Proposal of tunable fix for scalability of 8.4". > > So, if your goal is to find a scenario under which PostgreSQL performs > as badly as possible, congratulations - you've discovered the same > case that we already knew about. Obviously it would be nice to > improve it, but IIRC so far no one has had any very good ideas on how > to do that. If this example mimics a real-world workload that you > care about, and if using a connection pooler is just not a realistic > option in that scenario for whatever reason, then you'd be better off > working on how to fix it than on measuring it, because it seems to me > we already know it's got problems, per previous discussions. > > ...Robert >
В списке pgsql-performance по дате отправления:
Следующее
От: DimitriДата:
Сообщение: Re: What is the most optimal config parameters to keep stable write TPS ?..