Re: [HACKERS] Performance features the 4th
On Sun, 9 Nov 2003, Jan Wieck wrote: scott.marlowe wrote: On Fri, 7 Nov 2003, Matthew T. O'Connor wrote: - Original Message - From: Jan Wieck [EMAIL PROTECTED] Tom Lane wrote: Gaetano and a couple of other people did experiments that seemed to show it was useful. I think we'd want to change the shape of the knob per later suggestions (sleep 10 ms every N blocks, instead of N ms every block) but it did seem that there was useful bang for little buck there. I thought it was sleep N ms every M blocks. Have we seen any numbers? Anything at all? Something that gives us a clue by what factor one has to multiply the total time a VACUUM ANALYZE takes, to get what effect in return? I have some time on sunday to do some testing. Is there a patch that I can apply that implements either of the two options? (sleep 10ms every M blocks or sleep N ms every M blocks). I know Tom posted the original patch that sleept N ms every 1 block (where N is 10 due to OS limitations). Jan can you post a patch that has just the sleep code in it? Or should it be easy enough for me to cull out of the larger patch you posted? The reason for the change is that the minumum sleep period on many systems is 10mS, which meant that vacuum was running 20X slower than normal. While it might be necessary in certain very I/O starved situations to make it this slow, it would probably be better to be able to get a vacuum that ran at about 1/2 to 1/5 speed for most folks. So, since the delta can't less than 10mS on most systems, it's better to just leave it at a fixed amount and change the number of pages vacuumed per sleep. I disagree with that. If you limit yourself to the number of pages being the only knob you have and set the napping time fixed, you can only lower the number of sequentially read pages to slow it down. Making read ahead absurd in an IO starved situation ... I'll post a patch doing every N pages nap for M milliseconds using two GUC variables and based on a select(2) call later. I didn't mean fixed in the code I meant in your setup. I.e. find a delay (10mS, 50, 100 etc...) then vary the number of pages processed at a time until you start to notice the load, then back it off. Not being forced by the code to have one and only one delay value, setting it yourself. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Performance features the 4th
Yes, I would like to see the vacuum delay patch go into 7.4.1 if possible. It's really useful. I don't think there is any major risk in adding the delay patch into a minor revision given the small amount of code change. Stephen Matthew T. O'Connor [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: As a matter of fact, people who have performance problems are likely to be the same who have upgrade problems. And as Gaetano pointed out correctly, we will see wildforms with one or the other feature applied. I'd believe that for patches of the size of my original VACUUM-delay hack (or even a production-grade version of same, which'd probably be 10x larger). The kind of wholesale rewrite you are currently proposing is much too large to consider folding back into 7.4.*, IMHO. Do people think that the VACUUM-delay patch by itself, would be usefully enough on it's own to consider working it into 7.4.1 or something? From the little feedback I have read on the VACUUM-delay patch used in isolation, it certainly does help. I would love to see it put into 7.4 somehow. The far more rigorous changes that Jan is working on, will be welcome improvements for 7.5. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Performance features the 4th
Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: However, I have not seen much evidence yet that the vacuum delay alone does that much. Gaetano and a couple of other people did experiments that seemed to show it was useful. I think we'd want to change the shape of the knob per later suggestions (sleep 10 ms every N blocks, instead of N ms every block) but it did seem that there was useful bang for little buck there. Right, I'd like to try know the patch: sleep N ms every M blocks. Can you please post this patch ? BTW, I'll see if I'm able to apply it also to a 7.3.X ( our production DB). Regards Gaetano Mendola ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Performance features the 4th
scott.marlowe wrote: On Fri, 7 Nov 2003, Matthew T. O'Connor wrote: - Original Message - From: Jan Wieck [EMAIL PROTECTED] Tom Lane wrote: Gaetano and a couple of other people did experiments that seemed to show it was useful. I think we'd want to change the shape of the knob per later suggestions (sleep 10 ms every N blocks, instead of N ms every block) but it did seem that there was useful bang for little buck there. I thought it was sleep N ms every M blocks. Have we seen any numbers? Anything at all? Something that gives us a clue by what factor one has to multiply the total time a VACUUM ANALYZE takes, to get what effect in return? I have some time on sunday to do some testing. Is there a patch that I can apply that implements either of the two options? (sleep 10ms every M blocks or sleep N ms every M blocks). I know Tom posted the original patch that sleept N ms every 1 block (where N is 10 due to OS limitations). Jan can you post a patch that has just the sleep code in it? Or should it be easy enough for me to cull out of the larger patch you posted? The reason for the change is that the minumum sleep period on many systems is 10mS, which meant that vacuum was running 20X slower than normal. While it might be necessary in certain very I/O starved situations to make it this slow, it would probably be better to be able to get a vacuum that ran at about 1/2 to 1/5 speed for most folks. So, since the delta can't less than 10mS on most systems, it's better to just leave it at a fixed amount and change the number of pages vacuumed per sleep. I disagree with that. If you limit yourself to the number of pages being the only knob you have and set the napping time fixed, you can only lower the number of sequentially read pages to slow it down. Making read ahead absurd in an IO starved situation ... I'll post a patch doing every N pages nap for M milliseconds using two GUC variables and based on a select(2) call later. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Performance features the 4th
Matthew T. O'Connor wrote:
- Original Message -
From: Jan Wieck [EMAIL PROTECTED]
Tom Lane wrote:
Gaetano and a couple of other people did experiments that seemed to show
it was useful. I think we'd want to change the shape of the knob per
later suggestions (sleep 10 ms every N blocks, instead of N ms every
block) but it did seem that there was useful bang for little buck there.
I thought it was sleep N ms every M blocks.
Have we seen any numbers? Anything at all? Something that gives us a
clue by what factor one has to multiply the total time a VACUUM
ANALYZE takes, to get what effect in return?
I have some time on sunday to do some testing. Is there a patch that I can
apply that implements either of the two options? (sleep 10ms every M blocks
or sleep N ms every M blocks).
I know Tom posted the original patch that sleept N ms every 1 block (where N
is 10 due to OS limitations). Jan can you post a patch that has just the
sleep code in it? Or should it be easy enough for me to cull out of the
larger patch you posted?
Sorry for the delay, had to finish some other concept yesterday (will be
published soon).
The attached patch adds
vacuum_group_delay_size = 10 (range 1-1000)
vacuum_group_delay_msec = 0 (range 0-1000)
and does the sleeping via select(2). It does it only at the same places
where Tom had done the usleep() in his hack, so I guess there is still
some more to do besides the documentation, before it can be added to
7.4.1. But it should be enough to get some testing done.
Jan
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#== [EMAIL PROTECTED] #
Index: src/backend/access/nbtree/nbtree.c
===
RCS file: /home/pgsql/CvsRoot/pgsql-server/src/backend/access/nbtree/nbtree.c,v
retrieving revision 1.106
diff -c -b -r1.106 nbtree.c
*** src/backend/access/nbtree/nbtree.c 2003/09/29 23:40:26 1.106
--- src/backend/access/nbtree/nbtree.c 2003/11/09 23:39:36
***
*** 27,32
--- 27,40
#include storage/smgr.h
+ /*
+ * Variables for vacuum_group_delay option (in commands/vacuumlazy.c)
+ */
+ extern intvacuum_group_delay_size;/* vacuum N pages */
+ extern intvacuum_group_delay_msec;/* then sleep M msec */
+ extern intvacuum_group_delay_count;
+
+
/* Working state for btbuild and its callback */
typedef struct
{
***
*** 610,615
--- 618,632
CHECK_FOR_INTERRUPTS();
+ if (vacuum_group_delay_msec 0)
+ {
+ if (++vacuum_group_delay_count =
vacuum_group_delay_size)
+ {
+ PG_DELAY(vacuum_group_delay_msec);
+ vacuum_group_delay_count = 0;
+ }
+ }
+
ndeletable = 0;
page = BufferGetPage(buf);
opaque = (BTPageOpaque) PageGetSpecialPointer(page);
***
*** 736,741
--- 753,769
Buffer buf;
Pagepage;
BTPageOpaque opaque;
+
+ CHECK_FOR_INTERRUPTS();
+
+ if (vacuum_group_delay_msec 0)
+ {
+ if (++vacuum_group_delay_count = vacuum_group_delay_size)
+ {
+ PG_DELAY(vacuum_group_delay_msec);
+ vacuum_group_delay_count = 0;
+ }
+ }
buf = _bt_getbuf(rel, blkno, BT_READ);
page = BufferGetPage(buf);
Index: src/backend/commands/vacuumlazy.c
===
RCS file: /home/pgsql/CvsRoot/pgsql-server/src/backend/commands/vacuumlazy.c,v
retrieving revision 1.32
diff -c -b -r1.32 vacuumlazy.c
*** src/backend/commands/vacuumlazy.c 2003/09/25 06:57:59 1.32
--- src/backend/commands/vacuumlazy.c 2003/11/09 23:40:13
***
*** 88,93
--- 88,100
static TransactionId OldestXmin;
static TransactionId FreezeLimit;
+ /*
+ * Variables for vacuum_group_delay option (in commands/vacuumlazy.c)
+ */
+ int vacuum_group_delay_size = 10; /* vacuum N pages */
+ int vacuum_group_delay_msec = 0;/* then sleep M msec */
+ int vacuum_group_delay_count = 0;
+
/* non-export function prototypes */
static void lazy_scan_heap(Relation onerel, LVRelStats *vacrelstats,
***
*** 228,233
--- 235,249
CHECK_FOR_INTERRUPTS();
+ if (vacuum_group_delay_msec 0)
+ {
+
Re: [HACKERS] Performance features the 4th
Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: As a matter of fact, people who have performance problems are likely to be the same who have upgrade problems. And as Gaetano pointed out correctly, we will see wildforms with one or the other feature applied. I'd believe that for patches of the size of my original VACUUM-delay hack (or even a production-grade version of same, which'd probably be 10x larger). The kind of wholesale rewrite you are currently proposing is much too large to consider folding back into 7.4.*, IMHO. What Jan could do is to have a 7.4 patch available that people can test, and he can improve it during the 7.5 development cycle with feedback from users. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Performance features the 4th
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Bruce Momjian) wrote:
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
As a matter of fact, people who have performance problems are likely to
be the same who have upgrade problems. And as Gaetano pointed out
correctly, we will see wildforms with one or the other feature applied.
I'd believe that for patches of the size of my original VACUUM-delay
hack (or even a production-grade version of same, which'd probably be
10x larger). The kind of wholesale rewrite you are currently proposing
is much too large to consider folding back into 7.4.*, IMHO.
What Jan could do is to have a 7.4 patch available that people can test,
and he can improve it during the 7.5 development cycle with feedback
from users.
The thing is, there are two patches that seem likely to be of
interest:
a) There's the ARC changes, which really feel like they are 7.5
development, not likely to be readily backportable;
b) On the other hand, a simple delay on the VACUUM seems likely
to be useful, and reasonably backportable.
And these are two quite different things, both of which may be worth
having.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://www.ntlug.org/~cbbrowne/unix.html
If I could put Klein in a bottle...
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Performance features the 4th
Christopher Browne wrote: A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Bruce Momjian) wrote: Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: As a matter of fact, people who have performance problems are likely to be the same who have upgrade problems. And as Gaetano pointed out correctly, we will see wildforms with one or the other feature applied. I'd believe that for patches of the size of my original VACUUM-delay hack (or even a production-grade version of same, which'd probably be 10x larger). The kind of wholesale rewrite you are currently proposing is much too large to consider folding back into 7.4.*, IMHO. What Jan could do is to have a 7.4 patch available that people can test, and he can improve it during the 7.5 development cycle with feedback from users. The thing is, there are two patches that seem likely to be of interest: a) There's the ARC changes, which really feel like they are 7.5 development, not likely to be readily backportable; b) On the other hand, a simple delay on the VACUUM seems likely to be useful, and reasonably backportable. And these are two quite different things, both of which may be worth having. Yes, Tom has already said b is possible in a 7.4.X subrelease, but not for 7.4.0. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Performance features the 4th
Christopher Browne wrote: A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Bruce Momjian) wrote: Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: As a matter of fact, people who have performance problems are likely to be the same who have upgrade problems. And as Gaetano pointed out correctly, we will see wildforms with one or the other feature applied. I'd believe that for patches of the size of my original VACUUM-delay hack (or even a production-grade version of same, which'd probably be 10x larger). The kind of wholesale rewrite you are currently proposing is much too large to consider folding back into 7.4.*, IMHO. What Jan could do is to have a 7.4 patch available that people can test, and he can improve it during the 7.5 development cycle with feedback from users. The thing is, there are two patches that seem likely to be of interest: a) There's the ARC changes, which really feel like they are 7.5 development, not likely to be readily backportable; b) On the other hand, a simple delay on the VACUUM seems likely to be useful, and reasonably backportable. And these are two quite different things, both of which may be worth having. I only need to know the three W's, when, what and where (when do people want what pieces of the stuff where?). However, I have not seen much evidence yet that the vacuum delay alone does that much. In conjunction with putting vacuum dirtied blocks at LRU instead of MRU maybe, but that's again another functional change. So I am not sure what the outcome of that for 7.4 is. The general opinion is that the whole thing is too much. But nobody has done anything to show how the vacuum delay alone compares to that. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Performance features the 4th
Jan Wieck [EMAIL PROTECTED] writes: However, I have not seen much evidence yet that the vacuum delay alone does that much. Gaetano and a couple of other people did experiments that seemed to show it was useful. I think we'd want to change the shape of the knob per later suggestions (sleep 10 ms every N blocks, instead of N ms every block) but it did seem that there was useful bang for little buck there. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Performance features the 4th
Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: However, I have not seen much evidence yet that the vacuum delay alone does that much. Gaetano and a couple of other people did experiments that seemed to show it was useful. I think we'd want to change the shape of the knob per later suggestions (sleep 10 ms every N blocks, instead of N ms every block) but it did seem that there was useful bang for little buck there. I thought it was sleep N ms every M blocks. Have we seen any numbers? Anything at all? Something that gives us a clue by what factor one has to multiply the total time a VACUUM ANALYZE takes, to get what effect in return? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Performance features the 4th
- Original Message - From: Jan Wieck [EMAIL PROTECTED] Tom Lane wrote: Gaetano and a couple of other people did experiments that seemed to show it was useful. I think we'd want to change the shape of the knob per later suggestions (sleep 10 ms every N blocks, instead of N ms every block) but it did seem that there was useful bang for little buck there. I thought it was sleep N ms every M blocks. Have we seen any numbers? Anything at all? Something that gives us a clue by what factor one has to multiply the total time a VACUUM ANALYZE takes, to get what effect in return? I have some time on sunday to do some testing. Is there a patch that I can apply that implements either of the two options? (sleep 10ms every M blocks or sleep N ms every M blocks). I know Tom posted the original patch that sleept N ms every 1 block (where N is 10 due to OS limitations). Jan can you post a patch that has just the sleep code in it? Or should it be easy enough for me to cull out of the larger patch you posted? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Performance features the 4th
On Fri, 7 Nov 2003, Matthew T. O'Connor wrote: - Original Message - From: Jan Wieck [EMAIL PROTECTED] Tom Lane wrote: Gaetano and a couple of other people did experiments that seemed to show it was useful. I think we'd want to change the shape of the knob per later suggestions (sleep 10 ms every N blocks, instead of N ms every block) but it did seem that there was useful bang for little buck there. I thought it was sleep N ms every M blocks. Have we seen any numbers? Anything at all? Something that gives us a clue by what factor one has to multiply the total time a VACUUM ANALYZE takes, to get what effect in return? I have some time on sunday to do some testing. Is there a patch that I can apply that implements either of the two options? (sleep 10ms every M blocks or sleep N ms every M blocks). I know Tom posted the original patch that sleept N ms every 1 block (where N is 10 due to OS limitations). Jan can you post a patch that has just the sleep code in it? Or should it be easy enough for me to cull out of the larger patch you posted? The reason for the change is that the minumum sleep period on many systems is 10mS, which meant that vacuum was running 20X slower than normal. While it might be necessary in certain very I/O starved situations to make it this slow, it would probably be better to be able to get a vacuum that ran at about 1/2 to 1/5 speed for most folks. So, since the delta can't less than 10mS on most systems, it's better to just leave it at a fixed amount and change the number of pages vacuumed per sleep. I'm certainly gonna test the patch out too. We aren't really I/O bound, but it would be nice to have a database that only slowed down ~1% or so during vacuuming. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Performance features the 4th
Jan Wieck wrote: _Vacuum page delay_: Tom Lane's napping during vacuums with another tuning option. I replaced the usleep() call with a PG_DELAY(msec) macro in miscadmin.h, which does use select(2) instead. That should address the possible portability problems. What about skipping the delay if there are no outstanding disk operations? Then vacuum would get the full disk bandwidth if the system is idle. -- Manfred ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Performance features the 4th
Jan Wieck [EMAIL PROTECTED] writes: This patch contains the still not yet ready performance improvements discussed over the couple last days. Cool stuff! The buffer replacement strategy is a slightly modified version of ARC. BTW Jan, I got your message about taking a look at the ARC code; I'm really busy at the moment, but I'll definitely take a look at it when I get a chance. I personally would like to see this work included in a 7.4.x release. Personally, I can't see any circumstance under which I would view this as appropriate for integration into the 7.4 branch -- the changes this patch introduces are pretty fundamental to the system; even with testing I'd rather not see a stable release series potentially destabilized. Furthermore, it's not as if these performance issues have been recently discovered: we've been aware of most of them for at least one or two prior releases (if not much longer). -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Performance features the 4th
Manfred Spraul wrote: Jan Wieck wrote: _Vacuum page delay_: Tom Lane's napping during vacuums with another tuning option. I replaced the usleep() call with a PG_DELAY(msec) macro in miscadmin.h, which does use select(2) instead. That should address the possible portability problems. What about skipping the delay if there are no outstanding disk operations? Then vacuum would get the full disk bandwidth if the system is idle. All we could do is to monitor our own recent activity. I doubt that anything else would be portable. And on a dedicated DB server that is very close to the truth anyway. How portable is getrusage()? Could the postmaster issue that frequently for RUSAGE_CHILDREN and leave the result somewhere in the shared memory for whoever is concerned? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Performance features the 4th
Neil Conway wrote: Jan Wieck [EMAIL PROTECTED] writes: This patch contains the still not yet ready performance improvements discussed over the couple last days. Cool stuff! The buffer replacement strategy is a slightly modified version of ARC. BTW Jan, I got your message about taking a look at the ARC code; I'm really busy at the moment, but I'll definitely take a look at it when I get a chance. I personally would like to see this work included in a 7.4.x release. Personally, I can't see any circumstance under which I would view this as appropriate for integration into the 7.4 branch -- the changes this patch introduces are pretty fundamental to the system; even with testing I'd rather not see a stable release series potentially destabilized. Furthermore, it's not as if these performance issues have been recently discovered: we've been aware of most of them for at least one or two prior releases (if not much longer). There are many aspects to this, and a full consensus will probably not be reachable. As a matter of fact, people who have performance problems are likely to be the same who have upgrade problems. And as Gaetano pointed out correctly, we will see wildforms with one or the other feature applied. My opinion is that it is best for us as supporters and for the reputation of PostgreSQL to try to keep the number of wildforms as small as possible and to provide those features applied in the best possible quality. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Performance features the 4th
Jan Wieck wrote: How portable is getrusage()? Could the postmaster issue that frequently for RUSAGE_CHILDREN and leave the result somewhere in the shared memory for whoever is concerned? SVr4, BSD4.3, SUS2 and POSIX1003.1, I believe. I also believe there is a M$ dll available that gives that functionality (psapi.dll). cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Performance features the 4th
Andrew Dunstan wrote: Jan Wieck wrote: How portable is getrusage()? Could the postmaster issue that frequently for RUSAGE_CHILDREN and leave the result somewhere in the shared memory for whoever is concerned? SVr4, BSD4.3, SUS2 and POSIX1003.1, I believe. I also believe there is a M$ dll available that gives that functionality (psapi.dll). Remains the question when it is updated, the manpage doesn't tell. If the RUSAGE_CHILDREN information is updated only when the child exits, each backend has to do it. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Performance features the 4th
On Wed, Nov 05, 2003 at 03:08:53PM -0500, Neil Conway wrote: Jan Wieck [EMAIL PROTECTED] writes: I personally would like to see this work included in a 7.4.x release. Personally, I can't see any circumstance under which I would view this as appropriate for integration into the 7.4 branch -- the changes this As unhappy as I am to say so, I agree strongly. Dot releases don't get anything like enough testing to make me comfortable with putting this kind of patch into such a release. I'm just a user though. A -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, Ontario Canada [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Performance features the 4th
Jan Wieck [EMAIL PROTECTED] writes: Manfred Spraul wrote: What about skipping the delay if there are no outstanding disk operations? How portable is getrusage()? Could the postmaster issue that frequently for RUSAGE_CHILDREN and leave the result somewhere in the shared memory for whoever is concerned? How would that tell you about currently outstanding operations? Manfred's idea is interesting but AFAICS completely unimplementable in any portable fashion. You'd have to have hooks into the kernel. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Performance features the 4th
On Wed, Nov 05, 2003 at 03:49:54PM -0500, Jan Wieck wrote: Andrew Dunstan wrote: Jan Wieck wrote: How portable is getrusage()? Could the postmaster issue that frequently for RUSAGE_CHILDREN and leave the result somewhere in the shared memory for whoever is concerned? SVr4, BSD4.3, SUS2 and POSIX1003.1, I believe. I also believe there is a M$ dll available that gives that functionality (psapi.dll). Remains the question when it is updated, the manpage doesn't tell. If the RUSAGE_CHILDREN information is updated only when the child exits, each backend has to do it. If the value of the who argument is RUSAGE_CHILDREN, information shall be returned about resources used by the terminated and waited-for children of the current process Kurt ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Performance features the 4th
Jan Wieck [EMAIL PROTECTED] writes: As a matter of fact, people who have performance problems are likely to be the same who have upgrade problems. And as Gaetano pointed out correctly, we will see wildforms with one or the other feature applied. I'd believe that for patches of the size of my original VACUUM-delay hack (or even a production-grade version of same, which'd probably be 10x larger). The kind of wholesale rewrite you are currently proposing is much too large to consider folding back into 7.4.*, IMHO. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Performance features the 4th
Tom Lane wrote: Manfred's idea is interesting but AFAICS completely unimplementable in any portable fashion. You'd have to have hooks into the kernel. I thought about outstanding operations from postgres - I don't know enough about the buffer layer if it's possible to keep a counter of the currently running read() and write() operations, or something similar. -- Manfred ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Performance features the 4th
Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: As a matter of fact, people who have performance problems are likely to be the same who have upgrade problems. And as Gaetano pointed out correctly, we will see wildforms with one or the other feature applied. I'd believe that for patches of the size of my original VACUUM-delay hack (or even a production-grade version of same, which'd probably be 10x larger). The kind of wholesale rewrite you are currently proposing is much too large to consider folding back into 7.4.*, IMHO. Do people think that the VACUUM-delay patch by itself, would be usefully enough on it's own to consider working it into 7.4.1 or something? From the little feedback I have read on the VACUUM-delay patch used in isolation, it certainly does help. I would love to see it put into 7.4 somehow. The far more rigorous changes that Jan is working on, will be welcome improvements for 7.5. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
