On Wed, Feb 25, 2009 at 3:55 PM, Scott Marlowe <scott.marl...@gmail.com>wrote:
> On Wed, Feb 25, 2009 at 2:38 PM, Farhan Husain <russ...@gmail.com> wrote: > > > > > > On Wed, Feb 25, 2009 at 3:35 PM, Scott Marlowe <scott.marl...@gmail.com> > > wrote: > >> > >> On Wed, Feb 25, 2009 at 2:32 PM, Farhan Husain <russ...@gmail.com> > wrote: > >> > > >> > On Wed, Feb 25, 2009 at 3:30 PM, Robert Haas <robertmh...@gmail.com> > >> > wrote: > >> >> > >> >> On Wed, Feb 25, 2009 at 3:44 PM, Farhan Husain <russ...@gmail.com> > >> >> wrote: > >> >> > Initially, it was the default value (32MB). Later I played with > that > >> >> > value > >> >> > thinking that it might improve the performance. But all the values > >> >> > resulted > >> >> > in same amount of time. > >> >> > >> >> Well, if you set it back to what we consider to be a reasonable > value, > >> >> rerun EXPLAIN ANALYZE, and post that plan, it might help us tell you > >> >> what to do next. > >> >> > >> >> ...Robert > >> > > >> > Right now I am running the query again with 32MB work_mem. It is > taking > >> > a > >> > long time as before. However, I have kept the following values > >> > unchanged: > >> > > >> > shared_buffers = 32MB # min 128kB or > >> > max_connections*16kB > >> > >> That's REALLY small for pgsql. Assuming your machine has at least 1G > >> of ram, I'd set it to 128M to 256M as a minimum. > > > > As I wrote in a previous email, I had the value set to 1792MB (the > highest I > > could set) and had the same execution time. This value is not helping me > to > > bring down the execution time. > > No, that was work_mem. This is shared_buffers. > Oh, sorry for the confusion. I will change the shared_buffer once the current run finishes. -- Mohammad Farhan Husain Research Assistant Department of Computer Science Erik Jonsson School of Engineering and Computer Science University of Texas at Dallas
