per table random-page-cost?
in [PgSql]
|
From: Stefan Moeding on 24 Oct 2009 02:00 Hi! Josh Berkus writes: > Now, if we had an OS which could be convinced to handle caching > differently for different physical devices, then I could see wanting > this setting to be per-tablespace. For example, it would make a lot of > sense not to FS-cache any data which is on a ramdisk or superfast SSD > array. The same with archive data which you expected to be slow and > infrequently accessed on a NAS device. If your OS can do that, while > caching data from other sources, then it would make sense. > > However, I don't know any current OS which allows for this. Does anyone > else? Isn't bypassing the buffer cache exactly what direct I/O is about? Solaris UFS has a "forcedirectio" mount option, AIX JFS2 calls it "dio" and Veritas VxFS uses the "convosync=direct" option to disable caching the content of the filesystem. -- Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: =?utf-8?q?C=C3=A9dric_Villemain?= on 26 Oct 2009 13:19 Le samedi 24 octobre 2009 01:04:19, Josh Berkus a écrit : > Cedric, > > > ase is a table containing 29 GB of bytea in a database of 52 GB. Every > > row on the 29GB table is grab only few times. And it will just renew OS > > cache memory every time (the server have only 8GB of ram). > > So when I remove this table (not the index) from the OS cache memory, I > > keep more interesting blocks in the OS cache memory. > > effective_cache_size doesn't control what gets cached, it just tells the > planner about it. > > Now, if we had an OS which could be convinced to handle caching > differently for different physical devices, then I could see wanting > this setting to be per-tablespace. For example, it would make a lot of > sense not to FS-cache any data which is on a ramdisk or superfast SSD > array. The same with archive data which you expected to be slow and > infrequently accessed on a NAS device. If your OS can do that, while > caching data from other sources, then it would make sense. > > However, I don't know any current OS which allows for this. Does anyone > else? Isn't it what "fadvise -dontneed" let you do ? Josh, I talk about effective_cache_size per tablespace *exactly* for the reason you explain. -- Cédric Villemain Administrateur de Base de Données Cel: +33 (0)6 74 15 56 53 http://dalibo.com - http://dalibo.org
From: Bruce Momjian on 9 Nov 2009 18:56
Robert Haas wrote: > On Thu, Oct 22, 2009 at 2:28 PM, Josh Berkus <josh(a)agliodbs.com> wrote: > > All, > > > > Wouldn't per *tablespace* costs make more sense? > > > > --Josh > > Yes, we already had several votes in favor of that approach. See upthread. Added to TODO: Allow per-tablespace random_page_cost * http://archives.postgresql.org/pgsql-hackers/2009-10/msg01128.php -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |