Six PostgreSQL questions from a pokerplayer - Mailing list pgsql-performance
From | Patvs |
---|---|
Subject | Six PostgreSQL questions from a pokerplayer |
Date | |
Msg-id | 24337072.post@talk.nabble.com Whole thread Raw |
Responses |
Re: Six PostgreSQL questions from a pokerplayer
Re: Six PostgreSQL questions from a pokerplayer Re: Six PostgreSQL questions from a pokerplayer |
List | pgsql-performance |
I use poker software (HoldemManager) to keep track of the statistics (and show nice graphs) of millions of poker hand histories. This software (also PokerTracker 3) imports all the poker hands in PostgreSQL. The software runs on Windows) only. All of its users have NORMAL PCs. From single-core laptops, to a quadcore desktop at best. Questions: -1 [quote] "POSTGRESQL uses a multi-process model. Because of this, all multi-cpu operating systems can spread multiple database connections among the available CPUs. However, if only a single database connection is active, it can only use one CPU. POSTGRESQL does not use multi-threading to allow a single process to use multiple CPUs."[/quote] I can see two databases in my pgAdmin: postgres and HoldemManager. All the poker data (about 30 GB of data) is in the HoldemManager database. Does the quote above (if true?) means, having a 2 Ghz single core or a Xeon 2x quadcore (8x 2 Ghz cores) will make no real difference for my performance? And the real performance increase is only for professional servers running multiple databases? Will I greatly benefit from having quad instead of a single-core system? -2 In the recent 8.3 vs 8.4 benchmarks, 8.4. was much faster than 8.3 running on a 16 and 32 core server (with 64GB RAM). With 8 cores, they were about the same speed. Does this mean on a normal single core computer, there will be NO NOTICABLE performance increase in 8.3 vs 8.4 and even 8.2? -3 [quote] "With PostgreSQL, you could easily have more than 1GB per backend (if necessary) without running out of memory, which significantly pushes away the point when you need to go to 64-bit. In some cases it may actually be better to run a 32-bit build of PostgreSQL to reduce memory usage. In a 64-bit server, every pointer and every integer will take twice as much space as in a 32bit server. That overhead can be significant, and is most likely unnecessary." [/quote] I have no idea what the maximum amount of RAM is, my database uses. But what exactly "will take twice as much space"? Does this mean a simple database uses double the amount of RAM on a 64 bit system? And it's probably better for my 30 GB database to run a 32-bit build of PostgreSQL to reduce memory usage? -4 One a scale from 1 to 10, how significant are the following on performance increase: -[ ] Getting a faster harddisk (RAID or a SSD) -[ ] Getting a faster CPU -[ ] Upgrading PostgreSQL (8.2 and 8.3) to 8.4 -[ ] Tweaking PostgreSQL (increasing # shared_buffers, wal_buffers, effective_cache_size, etc.) -[10!] Something else? -[ ] Does NOT effect me, but I was wondering what a switch from Windows to LINUX/Solaris does for professional server users in terms of performance. -5 The IO operations/s performance of your harddisk vs read/write speeds vs access time? What is more important? With 4 regular harddisks in RAID0 you get great read/write speeds, but the SSDs excel in IO/s and a 0.1ms access time. What is the most usefull for which situations? -6 The 8.4.0-1 one-click installer automatically set the encoding to UTF8. With the other installers, I was able to change the encoding to SQL_ASCII during the installation process. How do I solve this after I've installed 8.4.0-1? (I was unable to delete the postgres database, so I couldn't create a new one with the right encoding in 8.4.0-1) -- View this message in context: http://www.nabble.com/Six-PostgreSQL-questions-from-a-pokerplayer-tp24337072p24337072.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
pgsql-performance by date: