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 по дате отправления: