Re: PostgreSQL win32 fragmentation issue

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: PostgreSQL win32 fragmentation issue
Дата
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA0FD9D@algol.sollentuna.se
обсуждение исходный текст
Ответ на Re: PostgreSQL win32 fragmentation issue  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
> > "DBCC SHOWCONTIG determines whether the table is heavily fragmented.
> > Table fragmentation occurs through the process of data
> modifications
> > (INSERT, UPDATE, and DELETE statements) made against the table.
> > Because these modifications are not ordinarily distributed equally
> > among the rows of the table, the fullness of each page can
> vary over
> > time. For queries that scan part or all of a table, such table
> > fragmentation can cause additional page reads. This hinders
> parallel scanning of data."
>
> But that's measuring something else I think. That's not
> looking at how the pages are physically mapped on disk, but
> at how tuples are spread across pages.. Maybe in sqlserver
> tuples can span pages?

I don't beleive they can (except for IMAGE and TEXT data, which is
handled like our TOAST data).

That said, it returns two numbers:
Scan Density, which shows how many more pages it needs to hit than what
would be ideal
and
Locical Scan Fragmentation, which shows the percentage of "out-of-order
pages" it hits. And isn't "out-of-order pages" exactly what file system
fragmentation would leave us?  The difference between the physical page
and the logical page location.

Given that they preallocate files, they only have this kind of
fragmentation at one level. Since we don't, we can have this both inside
the file and in the fliesystem. But it's still the same thing, isn't it?


//Magnus


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Christian Portugal"
Дата:
Сообщение: new index methods
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: new index methods