On Wed, Feb 25, 2009 at 3:55 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote:
No, that was work_mem. This is shared_buffers.On Wed, Feb 25, 2009 at 2:38 PM, Farhan Husain <russoue@xxxxxxxxx> wrote:
>
>
> On Wed, Feb 25, 2009 at 3:35 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx>
> wrote:
>>
>> On Wed, Feb 25, 2009 at 2:32 PM, Farhan Husain <russoue@xxxxxxxxx> wrote:
>> >
>> > On Wed, Feb 25, 2009 at 3:30 PM, Robert Haas <robertmhaas@xxxxxxxxx>
>> > wrote:
>> >>
>> >> On Wed, Feb 25, 2009 at 3:44 PM, Farhan Husain <russoue@xxxxxxxxx>
>> >> 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.
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
