| Id | date | Message |
|---|---|---|
| 2008-09-09 14:45:39.0 | ||
| 149732 | 2008-09-09 14:45:39.0 | On Wed, Sep 10, 2008 at 07:16:35AM +1200, Brent Wood wrote: > Given the general increase in typical hardware specs these days, > perhaps the default pg specs could be set for higher spec systems? Given the default shmem configuration on operating systems these days, upping the default will likely cause postgresql to not run at all. For some reason the shmem defaults in OSes have not been increased in line with the hardware specs, not sure what can be done about that. Have a nice day, -- Martijn van Oosterhout <noway@spam.com> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines. |
| 149754 | 2008-09-09 15:16:30.0 | On Wed, Sep 10, 2008 at 07:16:35AM +1200, Brent Wood wrote: > Pg does itself no favours by sticking with such pessimistic > defaults, and a novice user wanting to try it out will find tweaking > the pg configuration files for performance quite complicated. You do know that at install time, Pg does some elementary investigation of the system to see what it can set its defaults to, right? In addition, every time this comes up I find it perplexing. The idea seems to be that "novices" in databases should be excused from learning about their system and should expect a nearly-optimally tuned system out of the box. But there are so many variables involved in database tuning as to make such a claim hard to swallow. For instance . . . > fits their system best? I figure (somewhat simplistically) that most > settings are more related to available memory than anything else, so . . . your figuring here is indeed simplistic. Every day I see requests for help from people who have followed the rule of thumb "1/4 of memory for shared_buffers", except that they're also running apache+jakarta, MySQL, and a mail server on the same box. They wonder why the stock advice is so wrong. It's wrong because a general-purpose tool is almost never going to come pre-set for every possible workload you might want to throw at it. So even "how much memory" there is on the machine is a question that is harder to answer than it might seem. Disk layout, data access patterns, even the filesystem you choose can make significant differences in how the system performs. Finally, part of the reason people make these claims is because they tend to hold Postgres up against toy systems that are _not_ designed to scale up. A certain well known database product, for instance, has been struggling for the last several years to turn itself into a full-featured, high-volume, safe transactional system. But the seams keep showing, because it just wasn't designed for this workload in the first place. But it sure is fast out of the box on a single-user system! A -- Andrew Sullivan noway@spam.com +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-general mailing list (pgsql-noway@spam.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general |
| 149764 | 2008-09-09 15:35:01.0 | Robert Treat <noway@spam.com> writes: > http://www.it.iitb.ac.in/~chetanv/personal/acads/db/report_html/node10.html. > It isn't terribly informative, but it doesindicate one thing, someone else > was able to run query #6 correctly, while the above site claims it returns an > error. Now when I look at query#6 from that site, I notice it shows the > following syntax: > interval '1' year. > when I saw that, it jumped out at me as something that could be an issue, and > it is: Yeah. This is SQL spec syntax, but it's not fully implemented in Postgres: the grammar supports it but the info doesn't get propagated to interval_in, and interval_in wouldn't know what to do even if it did have the information that there was a YEAR qualifier after the literal. That's probably not good because it *looks* like we support the syntax, but in fact produce non-spec-compliant results. I think it might be better if we threw an error. Or someone could try to make it work, but given that no one has taken the slightest interest since Tom Lockhart left the project, I wouldn't hold my breath waiting for that. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-noway@spam.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general |
| 149788 | 2008-09-09 16:08:57.0 | On Tue, Sep 9, 2008 at 2:07 PM, Andrew Sullivan <noway@spam.com> wrote: > > . . . your figuring here is indeed simplistic. Every day I see > requests for help from people who have followed the rule of thumb "1/4 > of memory for shared_buffers", except that they're also running > apache+jakarta, MySQL, and a mail server on the same box. They wonder > why the stock advice is so wrong. It's wrong because a > general-purpose tool is almost never going to come pre-set for every > possible workload you might want to throw at it. So even "how much > memory" there is on the machine is a question that is harder to answer > than it might seem. Disk layout, data access patterns, even the > filesystem you choose can make significant differences in how the > system performs. Just as common is the beginner showing up with an 8 core opteron server with 64 Gigs of ram trying to get fast write transactions on a single 7200 rpm 500G sata drive. > Finally, part of the reason people make these claims is because they > tend to hold Postgres up against toy systems that are _not_ designed > to scale up. A certain well known database product, for instance, has > been struggling for the last several years to turn itself into a > full-featured, high-volume, safe transactional system. But the seams > keep showing, because it just wasn't designed for this workload in the > first place. But it sure is fast out of the box on a single-user > system! reference tweakers.net http://tweakers.net/reviews/649/8/database-test-sun-ultrasparc-t1-vs-punt-amd-opteron-pagina-8.html http://tweakers.net/reviews/661/6/database-test-intel-xeon-clovertown-x5355-pagina-6.html -- Sent via pgsql-general mailing list (pgsql-noway@spam.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general |