Re: [PERFORM] Speeding up Gist Index creations

2004-11-01 Thread Josh Berkus
Neil, > How so? sort_mem improves index creation for B+-tree because we > implement bulk loading; there is no implementation of bulk loading for > GiST, so I don't see how sort_mem will help. Ah, wasn't aware of that deficiency. -- Josh Berkus Aglio Database Solutions San Francisco ---

Re: [PERFORM] Speeding up Gist Index creations

2004-11-01 Thread Neil Conway
On Mon, 2004-11-01 at 11:01, Josh Berkus wrote: > > Gist indexes take a long time to create as compared > > to normal indexes is there any way to speed them up ? > > > > (for example by modifying sort_mem or something temporarily ) > > More sort_mem will indeed help. How so? sort_mem improves ind

Re: [PERFORM] Performance difference when using views

2004-11-01 Thread Simon Riggs
On Mon, 2004-11-01 at 21:40, Alvaro Nunes Melo wrote: > Hi, > > I have some views that are used to make some queries simplest. But when > I use them there is a performance loss, because the query don't use > indexes anymore. Below I'm sending the query with and without the view, > its execution ti

Re: [PERFORM] Performance difference when using views

2004-11-01 Thread Tom Lane
Alvaro Nunes Melo <[EMAIL PROTECTED]> writes: > I have some views that are used to make some queries simplest. But when > I use them there is a performance loss, because the query don't use > indexes anymore. Below I'm sending the query with and without the view, > its execution times, explains and

Re: [PERFORM] [PATCHES] [HACKERS] ARC Memory Usage analysis

2004-11-01 Thread Simon Riggs
On Wed, 2004-10-27 at 01:39, Josh Berkus wrote: > Thomas, > > > As a result, I was intending to inflate the value of > > effective_cache_size to closer to the amount of unused RAM on some of > > the machines I admin (once I've verified that they all have a unified > > buffer cache). Is that correc

[PERFORM] Performance difference when using views

2004-11-01 Thread Alvaro Nunes Melo
Hi, I have some views that are used to make some queries simplest. But when I use them there is a performance loss, because the query don't use indexes anymore. Below I'm sending the query with and without the view, its execution times, explains and the view's body. I didn't understood the why the

Re: [PERFORM] psql large RSS (1.6GB)

2004-11-01 Thread Josh Berkus
Tom, > Far more useful would be some sort of streaming API to let the > application process the rows as they arrive, or at least fetch the rows > in small batches (the V3 protocol supports the latter even without any > explicit use of a cursor). ÂI'm not sure if this can be bolted onto the > exist

[PERFORM] shared_buffers and Shared Memory Segments

2004-11-01 Thread Anjan Dave
Hello,   I am trying to understand the output of the ‘ipcs’ command during peak activity and how I can use it to possibly tune the shared_buffers…   Here’s what I see right now: (ipcs –m) – (Host is RHAS 3.0)   -- Shared Memory Segments key    shmid  owner  p

Re: [PERFORM] psql large RSS (1.6GB)

2004-11-01 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > No, I don't remember hearing this discussed and I don't think most > people would want libpq spilling to disk by default. Far more useful would be some sort of streaming API to let the application process the rows as they arrive, or at least fetch the ro

Re: [PERFORM] psql large RSS (1.6GB)

2004-11-01 Thread Bruce Momjian
Gavin Sherry wrote: > On Sat, 30 Oct 2004, Dustin Sallings wrote: > > > > If the solution is to just write a little client that uses perl > > > DBI to fetch rows one at a time and write them out, that's doable, > > > but it would be nice if psql could be made to "just work" without > > > the mon

Re: [PERFORM] psql large RSS (1.6GB)

2004-11-01 Thread Gavin Sherry
On Sat, 30 Oct 2004, Dustin Sallings wrote: > > If the solution is to just write a little client that uses perl > > DBI to fetch rows one at a time and write them out, that's doable, > > but it would be nice if psql could be made to "just work" without > > the monster RSS. > > It wouldn't

Re: [PERFORM] Thanks Chariot Solutions

2004-11-01 Thread D'Arcy J.M. Cain
On Sun, 31 Oct 2004 13:38:55 -0500 (EST) [EMAIL PROTECTED] wrote: > > Many thanks to Chariot Solutions, http://chariotsolutions.com, for > hosting Bruce Momjian giving one of his PostgreSQL seminars outside of > Philadelphia, PA yesterday. There were about sixty folks there, one > person driving f