Thread: Sluggish inserts/updates ?
I've got a system in which a row is being created by one process, a notify is sent, and another process finds and then deletes the row. This whole interchange seems to be taking about a second, which seems oddly slow. As far as I know, I have the fsync-on-anything turned off (*). I'm mainly wondering if I should index/not index the key of the table, and if I should blame the hardware or Postgres? The hard drive on the R&D server is pretty slow, although the CPU is pretty dang fast. I could also blame the notification system but that shouldn't be a problem, right? * Is there a good way to find out if this option is on/off? -- Adam Haberlach |A cat spends her life conflicted between a adam@newsnipple.com |deep, passionate, and profound desire for http://www.newsnipple.com |fish and an equally deep, passionate, and '88 EX500 '00 >^< |profound desire to avoid getting wet.
Adam Haberlach wrote: > > I've got a system in which a row is being created by one process, > a notify is sent, and another process finds and then deletes the > row. This whole interchange seems to be taking about a second, which > seems oddly slow. If you do it enough times without vacuum, the table grows quite big, even though it may look empty... > As far as I know, I have the fsync-on-anything > turned off (*). > > I'm mainly wondering if I should index/not index the key of the > table, and if I should blame the hardware or Postgres? Index would very likely help. (BTW, the best way to find out is to try it - you can always drop it later ;) > The hard > drive on the R&D server is pretty slow, although the CPU is pretty > dang fast. I could also blame the notification system but that > shouldn't be a problem, right? How do you read the notify ? ---------- Hannu