Re: Air-traffic benchmark
От | Alvaro Herrera |
---|---|
Тема | Re: Air-traffic benchmark |
Дата | |
Msg-id | 20100107141423.GC4315@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Air-traffic benchmark (Lefteris <lsidir@gmail.com>) |
Ответы |
Re: Air-traffic benchmark
Re: Air-traffic benchmark Re: Air-traffic benchmark |
Список | pgsql-performance |
Lefteris escribió: > Yes, I am reading the plan wrong! I thought that each row from the > plan reported the total time for the operation but it actually reports > the starting and ending point. > > So we all agree that the problem is on the scans:) > > So the next question is why changing shared memory buffers will fix > that? i only have one session with one connection, do I have like many > reader workers or something? No amount of tinkering is going to change the fact that a seqscan is the fastest way to execute these queries. Even if you got it to be all in memory, it would still be much slower than the other systems which, I gather, are using columnar storage and thus are perfectly suited to this problem (unlike Postgres). The talk about "compression ratios" caught me by surprise until I realized it was columnar stuff. There's no way you can get such high ratios on a regular, row-oriented storage. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-performance по дате отправления: