Re: [PERFORM] Making the most of memory?

On Jan 22, 2008 10:11 PM, Joshua Fielek <[EMAIL PROTECTED]> wrote: > > Hey folks -- > > For starters, I am fairly new to database tuning and I'm still learning > the ropes. I understand the concepts but I'm still learning the real > world impact of some of the configuration options for postgres. >

[PERFORM] Making the most of memory?

Hey folks -- For starters, I am fairly new to database tuning and I'm still learning the ropes. I understand the concepts but I'm still learning the real world impact of some of the configuration options for postgres. We have an application that has been having some issues with performance

Re: [PERFORM] Workaround for cross column stats dependency

On Jan 23, 2008 2:43 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > regression=# create or replace function getu2(int) returns int[] as $$ > select array(select unique2 from tenk1 where thousand = $1); > $$ language sql immutable; > CREATE FUNCTION > regression=# explain select * from tenk1 where unique

Re: [PERFORM] Workaround for cross column stats dependency

"Guillaume Smet" <[EMAIL PROTECTED]> writes: > So the question is: is there any way to improve the results of the > original query, other than doing a first query in the application to > get the list of types and inject them in a second query (the one just > above)? Well, if you're willing to chea

[PERFORM] Workaround for cross column stats dependency

Hi -performance, While testing 8.3, I found this query which is equally slow on 8.1 and 8.3 and seems to be really slow for a not so complex query. The stats are as good as possible and the behaviour of PostgreSQL seems to be logical considering the stats but I'm looking for a workaround to speed

Re: [PERFORM] Optimizing queries that use temporary tables

On Jan 22, 2008 1:32 PM, Luiz K. Matsumura <[EMAIL PROTECTED]> wrote: > Hello, > > I'm developing some routines that will use temporary tables and need > advice on how to not lose performance. > > I will insert data in a temporary table and use this data to generate > new sets that will update or a

Re: [PERFORM] SELECT * FROM table is too slow

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 22 Jan 2008 17:44:33 -0200 "Luiz K. Matsumura" <[EMAIL PROTECTED]> wrote: > > > > Joshua D. Drake wrote:Hi, > > If we run the commands "vacumm full analyze" and "reindex table", > this can be considered as equivalent to making a dump / resto

Re: [PERFORM] SELECT * FROM table is too slow

Adam PAPAI wrote: Hi pgsql-performance, I've a problem with the select * on a small table. See below: x7=# SELECT count(idn) from megjelenesek; count --- 162 (1 row) Why does it take cca 18-20 sec to get the results? Too many indexes? You likely have a huge amount of dead rows. T

[PERFORM] Optimizing queries that use temporary tables

Hello, I'm developing some routines that will use temporary tables and need advice on how to not lose performance. I will insert data in a temporary table and use this data to generate new sets that will update or add to the same temporary table. I have some questions that I'm concerned abo

Re: [PERFORM] 8.3 synchronous_commit

Greg Smith wrote: Try something more in the range of 4 clients/CPU and set the scale to closer to twice that (so with a dual-core system you might do 8 clients and a scale of 16). If you really want to simulate a large number of clients, do that on another system and connect to the server remo

Re: [PERFORM] 8.3 synchronous_commit

Guillaume Smet wrote: Also with SATA? If your SATA disk is lying about effectively SYNCing the data, I'm not that surprised you don't see any improvement. Being slower is a bit surprising though. The disc is not lying, but LVM does not support write barriers, so the result is the same. Indeed

Re: [PERFORM] 8.3 synchronous_commit

* Guillaume Smet: > On Jan 22, 2008 9:32 AM, Florian Weimer <[EMAIL PROTECTED]> wrote: >> > Maybe it's just my test box.. single SATA-II drive, XFS on top of LVM. >> >> Ours was ext3, no LVM or RAID. > > Also with SATA? Yes, desktop-class SATA. > If your SATA disk is lying about effectively SYNC

Re: [PERFORM] 8.3 synchronous_commit

On Jan 22, 2008 9:32 AM, Florian Weimer <[EMAIL PROTECTED]> wrote: > > Maybe it's just my test box.. single SATA-II drive, XFS on top of LVM. > > Ours was ext3, no LVM or RAID. Also with SATA? If your SATA disk is lying about effectively SYNCing the data, I'm not that surprised you don't see any i

Re: [PERFORM] scheduler

Deadline works best for us. The new AS is getting better, but last we tried there were issues with it. - Luke > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Adrian Moisey > Sent: Monday, January 21, 2008 11:01 PM > To: pgsql-performance@postg

Re: [PERFORM] scheduler

On Tue, 22 Jan 2008, Adrian Moisey wrote: Hi Which scheduler is recommended for a box that is dedicated to running postgres? I've asked google and found no answers. Is it the OS itself? Yes, in linux. I've found that cfq or deadline is best, but I haven't seen anyone try a benchmark i

Re: [PERFORM] 8.3 synchronous_commit

* Hannes Dorbath: > I might completely misunderstand this feature. Shouldn't > "synchronous_commit = off" improve performance? Indeed. We've seen something similar in one test, but couldn't reproduce it in a clean environment so far. > Maybe it's just my test box.. single SATA-II drive, XFS on

Re: [PERFORM] scheduler

Hi Which scheduler is recommended for a box that is dedicated to running postgres? I've asked google and found no answers. Is it the OS itself? Yes, in linux. I've found that cfq or deadline is best, but I haven't seen anyone try a benchmark -- Adrian Moisey System Administrator | Caree

Re: [PERFORM] scheduler

> Which scheduler is recommended for a box that is dedicated to running > postgres? > > I've asked google and found no answers. Is it the OS itself? -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare --