Re: Air-traffic benchmark
От | Craig Ringer |
---|---|
Тема | Re: Air-traffic benchmark |
Дата | |
Msg-id | 4B46A6FD.5070106@postnewspapers.com.au обсуждение исходный текст |
Ответ на | Re: Air-traffic benchmark ("Gurgel, Flavio" <flavio@4linux.com.br>) |
Ответы |
Re: Air-traffic benchmark
|
Список | pgsql-performance |
On 7/01/2010 11:45 PM, Gurgel, Flavio wrote: >>> The table is very wide, which is probably why the tested databases >> can >>> deal with it faster than PG. You could try and narrow the table >> down >>> (for instance: remove the Div* fields) to make the data more >>> "relational-like". In real life, speedups in this circumstances >> would >>> probably be gained by normalizing the data to make the basic table >>> smaller and easier to use with indexing. > > Ugh. I don't think so. That's why indexes were invented. PostgreSQL is smart enough to "jump" over columns using byte offsets. Even if Pg tried to do so, it would generally not help. The cost of a disk seek to the start of the next row would be much greater than the cost of continuing to sequentially read until that point was reached. With the amazing sequential read speeds and still mediocre seek speeds modern disks it's rarely worth seeking over unwanted data that's less than a megabyte or two in size. Anyway, in practice the OS-level, array-level and/or disk-level readahead would generally ensure that the data you were trying to skip had already been read or was in the process of being read. Can Pg even read partial records ? I thought it all operated on a page level, where if an index indicates that a particular value is present on a page the whole page gets read in and all records on the page are checked for the value of interest. No? -- Craig Ringer
В списке pgsql-performance по дате отправления: