RE: [GENERAL] Benchmarks - Mailing list pgsql-general

I would help if you could provide the code for your function and create
trigger.


> -----Original Message-----
> From:    soundar rajan [SMTP:psrajan@yahoo.com]
> Sent:    Friday, January 07, 2000 8:13 AM
> To:    Michael J Davis; pgsql-general@hub.org
> Subject:    RE: [GENERAL] Benchmarks
>
> Can anyone hellp me out in creating a simple function
> and a trigger ?  When I create a function which
> returns opaque, I get an error stating 'sql function
> cannot return opaque'.  When I create a function which
> returns either int or varchar, I could create it, but,
> on invoking the function while creating the trigger, I
> get an error message stating the 'xxx' function must
> return opaque.  I get into a cycle of errors.  Any
> help to get out of the cycle (if possible with a small
> example code ?).  Thanks in advance.
>
>
>
> --- Michael J Davis <michael.j.davis@tvguide.com>
> wrote:
> > Maybe vacuum should be changed to automatically drop
> > all indexes, vacuum,
> > and re-create all indexes and stop trying to rebuild
> > each index.
> >
> > > -----Original Message-----
> > > From:    Culberson, Philip
> > [SMTP:philip.culberson@dat.com]
> > > Sent:    Thursday, January 06, 2000 1:58 PM
> > > To:    'Bruce Momjian'; Dustin Sallings
> > > Cc:    The Hermit Hacker; pgsql-general@hub.org
> > > Subject:    RE: [GENERAL] Benchmarks
> > >
> > > In his very insightful post last week, Mike
> > Mascari pointed out that, on
> > > tables with heavy insert/updates, it was much
> > faster to drop the index,
> > > vacuum analyze, and then rebuild the index.  Maybe
> > in vacuum there is a
> > > specific inefficiency in what Mike coined
> > "defragment"ing indexes.
> > >
> > > [Snip]
> > >
> > > 8. Not running VACUUM - PostgreSQL won't use
> > indexes, or won't optimize
> > > correctly unless the record count and dispersion
> > estimates are up-to-date.
> > > People have reported problems with running vacuum
> > while under heavy load.
> > > We
> > > haven't seen it, but we run vacuum each night at
> > 4:05 a.m. However, if you
> > > perform a LARGE number of INSERTS/UPDATES, it is
> > better for you to do the
> > > following:
> > >
> > > DROP INDEX index_on_heavilty_used_table;
> > > VACUUM ANALYZE;
> > > CREATE INDEX index_on_heavily_used_table;
> > >
> > > Because VACUUM will sit there, and, row by row,
> > essentially "defragment"
> > > your indexes, which can take damn near forever for
> > any number of updates
> > > or
> > > deletes greater than, say, 30,000 rows.
> > >
> > > [Snip]
> > >
> > > -----Original Message-----
> > > From: Bruce Momjian
> > [mailto:pgman@candle.pha.pa.us]
> > > Sent: Thursday, January 06, 2000 10:14 AM
> > > To: Dustin Sallings
> > > Cc: The Hermit Hacker; pgsql-general@hub.org
> > > Subject: Re: [GENERAL] Benchmarks
> > >
> > >
> > > >     Untrue, vacuum is *extremely* important for
> > updating statistics.
> > > > If you have a lot of data in a table, and you
> > have never vacuumed, you
> > > > might as well not have any indices.  It'd be
> > nice if you could seperate
> > > > the stat update from the storage reclaim.
> > Actually, it'd be nice if you
> > > > could reuse storage, so that an actual vacuum
> > wouldn't be necessary
> > > unless
> > > > you just wanted to free up disk space you might
> > end up using again
> > > anyway.
> > > >
> > > >     The vacuum also doesn't seem to be very
> > efficient.  In one of my
> > > > databases, a vacuum could take in excess of 24
> > hours, while I've written
> > > a
> > > > small SQL script that does a select rename and a
> > insert into select from
> > > > that will do the same job in about ten minutes.
> > This is a database that
> > > > cannot lock for more than a few minutes.
> > >
> > > This is serious.  Why would an INSERT / RENAME be
> > so much faster.  Are
> > > we that bad with VACUUM?
> > >
> > > --
> > >   Bruce Momjian                        |
> > http://www.op.net/~candle
> > >   maillist@candle.pha.pa.us            |  (610)
> > 853-3000
> > >   +  If your life is a hard drive,     |  830
> > Blythe Avenue
> > >   +  Christ can be your backup.        |  Drexel
> > Hill, Pennsylvania 19026
> > >
> > > ************
> > >
> > > ************
> >
> > ************
> >
>
>
> =====
> Thanks.
> Soundar.
> __________________________________________________
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com