Location for pgstat.stat
in [PgSql]
|
From: Magnus Hagander on 1 Jul 2008 14:48 Per this thread: http://archives.postgresql.org/pgsql-general/2007-12/msg00255.php it was pretty much (again, IIRC) concluded that we want "some better way" to transfer the stats data. But pending that we have that, how about we just move it into it's own subdirectory? AFAICS that would be a simple change of two #defines moving it from "global/pgstat.stat" to "pgstat/pgstat.stat" or something like that. Might also need some code to create the directory if it doesn't exist, but that shouldn't be hard. This would make it possible to symlink or mount that directory off to a ramdrive (for example). It's not a perfect solution, but it would at least give a better tool than we have today, no? //Magnus -- 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: Tom Lane on 1 Jul 2008 14:56 Magnus Hagander <magnus(a)hagander.net> writes: > But pending that we have that, how about we just move it into it's own > subdirectory? > This would make it possible to symlink or mount that directory off to a > ramdrive (for example). Hmm ... that would almost certainly result in the stats being lost over a system shutdown. How much do we care? regards, tom lane -- 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: Magnus Hagander on 1 Jul 2008 14:58 Tom Lane wrote: > Magnus Hagander <magnus(a)hagander.net> writes: >> But pending that we have that, how about we just move it into it's own >> subdirectory? >> This would make it possible to symlink or mount that directory off to a >> ramdrive (for example). > > Hmm ... that would almost certainly result in the stats being lost over > a system shutdown. How much do we care? Only for those who put it on a ramdrive. The default, unless you move/sync it off, would still be the same as it is today. While not perfect, the performance difference of going to a ramdrive might easily be enough to offset that in some cases, I think. //Magnus -- 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: Tom Lane on 1 Jul 2008 15:11 Magnus Hagander <magnus(a)hagander.net> writes: > Tom Lane wrote: >> Hmm ... that would almost certainly result in the stats being lost over >> a system shutdown. How much do we care? > Only for those who put it on a ramdrive. The default, unless you > move/sync it off, would still be the same as it is today. While not > perfect, the performance difference of going to a ramdrive might easily > be enough to offset that in some cases, I think. Well, what I was wondering about is whether it'd be worth adding logic to copy the file to/from a "safer" location at startup/shutdown. regards, tom lane -- 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: Magnus Hagander on 1 Jul 2008 15:18
Tom Lane wrote: > Magnus Hagander <magnus(a)hagander.net> writes: >> Tom Lane wrote: >>> Hmm ... that would almost certainly result in the stats being lost over >>> a system shutdown. How much do we care? > >> Only for those who put it on a ramdrive. The default, unless you >> move/sync it off, would still be the same as it is today. While not >> perfect, the performance difference of going to a ramdrive might easily >> be enough to offset that in some cases, I think. > > Well, what I was wondering about is whether it'd be worth adding logic > to copy the file to/from a "safer" location at startup/shutdown. Oh, I see. I should think more before I answer sometimes :-) Not sure. I guess my own personal concern would be how badly is autovacuum affected by having to start off a blank set of stats? Any other uses I have I think are capable of dealing with reset-to-zero states. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |