Re: [PERFORM] PostgreSQL as a local in-memory cache

On Thu, Jun 17, 2010 at 1:29 PM, Josh Berkus wrote: > a) Eliminate WAL logging entirely In addition to global temporary tables, I am also planning to implement unlogged tables, which are, precisely, tables for which no WAL is written. On restart, any such tables will be truncated. That should g

Re: [PERFORM] Low perfomance SUM and Group by large databse

On 21/06/10 22:42, Sergio Charpinel Jr. wrote: > Hi, > > I'm getting low performance on SUM and GROUP BY queries. > How can I improve my database to perform such queries. >-> Sort (cost=3499863.27..3523695.89 rows=9533049 > width=50) (actual time=165468.022..168908.828 rows=9494

Re: [PERFORM] mysql to postgresql, performance questions

On Mon, Jun 21, 2010 at 12:02 PM, Thom Brown wrote: > I thought I'd attempt to renew discussion of adding PostgreSQL support > to MythTV, but here's the response: > >> It is not being actively developed to my knowledge and we have >> no intention of _ever_ committing such patches. Any work you do

Re: [PERFORM] mysql to postgresql, performance questions

On 31 March 2010 15:23, Bruce Momjian wrote: > James Mansion wrote: >> Hannu Krosing wrote: >> > Pulling the plug should not corrupt a postgreSQL database, unless it was >> > using disks which lie about write caching. >> > >> Didn't we recently put the old wife's 'the disks lied' tale to bed in >>

Re: [PERFORM] Aggressive autovacuuming ?

Jesper Krogh wrote: > My thought was that if I tuned autovacuum to be "really > aggressive" then I could get autovacuum to actually vacuum the > tuples before they get evicted from the OS cache thus effectively > "saving" the IO-overhead of vacuuming. Interesting concept. That might be a way

Re: [PERFORM] Aggressive autovacuuming ?

Excerpts from Scott Marlowe's message of dom jun 20 16:13:15 -0400 2010: > On Sun, Jun 20, 2010 at 11:44 AM, Jesper Krogh wrote: > > Hi. > > > > I have been wondering if anyone has been experimenting with "really > > agressive" > > autovacuuming. > > I have been using moderately aggressive autova

Re: [PERFORM] Slow function in queries SELECT clause.

Thanks Tom, Your concepts of "inlining" and "black box" really cleared things up for me. With fnc_unit_convert() written in SQL and declared as STABLE I indeed have fast performance now. I appreciate the note on the IMMUTABLE part. The table contents should not change in a way to affect the fu

[PERFORM] Low perfomance SUM and Group by large databse

Hi, I'm getting low performance on SUM and GROUP BY queries. How can I improve my database to perform such queries. Here is my table schema: => \d acct_2010_25 Tabela "public.acct_2010_25" Coluna |Tipo | Modificadores -

Re: [PERFORM] HashAggregate slower than sort?

"Jatinder Sangha" wrote: > I've already converted all of my SQL to use "distinct on (...)" > and this is now always faster using the hash-aggregates than when > using sorting. The queries now only use sorting if the hashing > would take up too much memory. It's great that you have a solution

Re: [PERFORM] HashAggregate slower than sort?

Hi Kevin, Thanks for the suggestions. I've already converted all of my SQL to use "distinct on (...)" and this is now always faster using the hash-aggregates than when using sorting. The queries now only use sorting if the hashing would take up too much memory. Thanks, --Jatinder -Original