From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Lefteris <lsidir(at)gmail(dot)com> |
Cc: | Jochen Erwied <jochen(at)pgsql-performance(dot)erwied(dot)eu>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Air-traffic benchmark |
Date: | 2010-01-07 14:14:23 |
Message-ID: | 20100107141423.GC4315@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2010-01-07 14:16:38 | Re: Air-traffic benchmark |
Previous Message | Lefteris | 2010-01-07 14:10:20 | Re: Air-traffic benchmark |