Shridhar Daithankar wrote:
On 16 Jul 2003 at 19:09, Kirill Ponazdyr wrote:
It is for a advanced syslog server product we are currently developing.
The very basic idea is to feed all syslog messages into a DB and allow easy monitoring and even correlation, we use Postgres as our DB Backend, in big environments the machine would be hit with dozens of syslog messages in a second and the messaging tables could grow out of controll pretty soon (We are talking of up to 10mil messages daily).
You are looking at wrong end of pipe with fifo approach.
What I would do.
1. Create an empty table.
2. Create a table stamped with date and time. Let's call it 'T'
3. Create rule on original table to direct all the processing to 'T'.
4. Do record counting in middleware application. A mutex in application would be far less expensive than PG locking mechanism with disk.
When 'T' fills
a. create another table 'T1', b. rewrite rules accordingly
and bingo you are done.
Do (a) and (b) in transaction and nobody would notice the difference.No vacuum drag, no dead tuples nothing. And you are free to play with 'T' the way you want, completely independently.
I am sure this will work barring relations between rules and transaction. I don't know if rewriting rules is transaction safe or not. Most probably yes but would like to confirm that.
Bye Shridhar
--
What's this script do? unzip ; touch ; finger ; mount ; gasp ; yes ; umount ; sleepHint for the answer: not everything is computer-oriented. Sometimes you'rein a sleeping bag, camping out.(Contributed by Frans van der Zande.)
---------------------------(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
---------------------------(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
