Re: Hardware/OS recommendations for large databases (
От | Mark Kirkwood |
---|---|
Тема | Re: Hardware/OS recommendations for large databases ( |
Дата | |
Msg-id | 437E67EE.4070605@paradise.net.nz обсуждение исходный текст |
Ответ на | Re: Hardware/OS recommendations for large databases ( ("Luke Lonergan" <llonergan@greenplum.com>) |
Ответы |
Re: Hardware/OS recommendations for large databases (
Re: Hardware/OS recommendations for large databases ( |
Список | pgsql-performance |
Luke Lonergan wrote: > (mass snippage) > time psql -c "select count(*) from ivp.bigtable1" dgtestdb > [llonergan@modena2 IVP]$ cat sysout3 > count > ---------- > 80000000 > (1 row) > > > real 1m9.875s > user 0m0.000s > sys 0m0.004s > [llonergan@modena2 IVP]$ !du > du -sk dgtestdb/base > 17021260 dgtestdb/base > > > Summary: > > <cough, cough> OK – you can get more I/O bandwidth out of the current > I/O path for sequential scan if you tune the filesystem for large > readahead. This is a cheap alternative to overhauling the executor to > use asynch I/O. > > Still, there is a CPU limit here – this is not I/O bound, it is CPU > limited as evidenced by the sensitivity to readahead settings. If the > filesystem could do 1GB/s, you wouldn’t go any faster than 244MB/s. > > Luke, Interesting - but possibly only representative for a workload consisting entirely of one executor doing "SELECT ... FROM my_single_table". If you alter this to involve more complex joins (e.g 4. way star) and (maybe add a small number of concurrent executors too) - is it still the case? Cheers Mark
В списке pgsql-performance по дате отправления: