Re: optimizing vacuum truncation scans

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: optimizing vacuum truncation scans
Дата
Msg-id CA+TgmobvYg8940L6PMvD0b9vXA3KZNa+2bV58909_bHVhvJsFQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: optimizing vacuum truncation scans  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Список pgsql-hackers
On Mon, Sep 28, 2015 at 2:05 AM, Haribabu Kommi
<kommi.haribabu@gmail.com> wrote:
> I got the following way to get the whether data file is present in the
> DISK or SSD.
>
> 1. Get the device file system that table data file is mapped using the
> following or similar.
>
> df -P "filename" | awk 'NR==2{print $1}'
>
> 2. if the device file system is of type /dev/sd* then treat is as a
> disk system and proceed
> with the prefetch optimization.
>
> 3. if we are not able to find the device details directly then we need
> to get the information
> from the mapping system.
>
> Usually the devices will map like the following
>
> /dev/mapper/v** points to ../dm-*
>
> 4. Get the name of the "dm-*"  from the above details and check
> whether it is a SSD or not
> with the following command.
>
> /sys/block/dm-*/queue/rotation
>
> 5. If the value is 0 then it is an SSD drive, 1 means disk drive.
>
> The described above procedure works only for linux. I didn't check for
> other operating systems yet.
> Is it worth to consider?

No.  If we need to have the behavior depend on the hardware, it should
be a GUC or tablespace option or reloption, not some kind of crazy
OS-dependent discovery.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: track_commit_timestamp and COMMIT PREPARED
Следующее
От: Robert Haas
Дата:
Сообщение: Re: track_commit_timestamp and COMMIT PREPARED