Re: Postgresql "FIFO" Tables, How-To ?

From: Dennis Gearon <gearond(at)cvc(dot)net>
To: shridhar_daithankar(at)persistent(dot)co(dot)in
Cc: pg_general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Postgresql "FIFO" Tables, How-To ?
Date: 2003-07-17 15:15:28
Message-ID: 3F16BD90.1060809@cvc.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

What you don't get is a look at the maximum number of records when T is full and T1 is half full. How will you pull out half of the records in T1 and half of the records in T?

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
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Doug McNaught 2003-07-17 15:22:14 Re: Where is the physical files of database that I just
Previous Message Terence Chang 2003-07-17 15:11:48 Re: Where is the physical files of database that I just