> Here is the latest output:
>
> ingentadb=# EXPLAIN ANALYZE select A0.Subj, A2.Obj From jena_g1t1_stmt A0,
> jena_g1t1_stmt A1, jena_g1t1_stmt A2 Where
> A0.Prop='Uv::http://prismstandard.org/namespaces/1.2/basic/isPartOf' AND
> A0.Obj='Uv::http://www.utdallas.edu/~farhan.husain/IngentaConnect/iss
I will second Kevin's suggestion. Unless you think you will have more than a
few dozen concurrent queries, start with work_mem around 32MB.
For the query here, a very large work_mem might help it hash join depending on
the data... But that's not the real problem here.
The real problem is that i
>>> Farhan Husain wrote:
> Kevin Grittner > >>> Farhan Husain wrote:
>> > The machine postgres is running on has 4 GB of RAM.
>>
>> In addition to the other suggestions, you should be sure that
>> effective_cache_size is set to a reasonable value, which would
>> probably be somewhere in the neig
On Wed, Feb 25, 2009 at 4:10 PM, Kevin Grittner wrote:
> >>> Farhan Husain wrote:
> > The machine postgres is running on has 4 GB of RAM.
>
> In addition to the other suggestions, you should be sure that
> effective_cache_size is set to a reasonable value, which would
> probably be somewhere in
>>> Farhan Husain wrote:
> The machine postgres is running on has 4 GB of RAM.
In addition to the other suggestions, you should be sure that
effective_cache_size is set to a reasonable value, which would
probably be somewhere in the neighborhood of '3GB'. This doesn't
affect actual RAM allocat
I am trying to find the reason of the problem so going to Oracle or
something else is not the solution. I tried with several combinations of
those parameters before posting the problem here. I have read
http://www.postgresql.org/docs/current/interactive/runtime-config-resource.htmlbefore
and I thin
Wed, 25 Feb 2009 15:43:49 -0600 -n
Farhan Husain írta:
OK, you have two options:
1. Learn to read carefully, and differentiate between work_mem and
shared_buffers options. Lower work_mem and rise shared_buffers as
others wrote.
2. Leave Postgresql alone and go for Oracle or Microsoft SQL...
Rgd
On Wed, Feb 25, 2009 at 3:55 PM, Scott Marlowe wrote:
> On Wed, Feb 25, 2009 at 2:38 PM, Farhan Husain wrote:
> >
> >
> > On Wed, Feb 25, 2009 at 3:35 PM, Scott Marlowe
> > wrote:
> >>
> >> On Wed, Feb 25, 2009 at 2:32 PM, Farhan Husain
> wrote:
> >> >
> >> > On Wed, Feb 25, 2009 at 3:30 PM, Ro
On Wed, Feb 25, 2009 at 2:38 PM, Farhan Husain wrote:
>
>
> On Wed, Feb 25, 2009 at 3:35 PM, Scott Marlowe
> wrote:
>>
>> On Wed, Feb 25, 2009 at 2:32 PM, Farhan Husain wrote:
>> >
>> > On Wed, Feb 25, 2009 at 3:30 PM, Robert Haas
>> > wrote:
>> >>
>> >> On Wed, Feb 25, 2009 at 3:44 PM, Farhan
It was only after I got this high execution time when I started to look into
the configuration file and change those values. I tried several combinations
in which all those values were higher than the default values. I got no
improvement in runtime. The machine postgres is running on has 4 GB of RA
>> > 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
> co
What is random_page_cost set to? You could try to lower it to 1.5 if set higher.
--
regards
Claus
When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.
Shakespeare
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes t
On Wed, Feb 25, 2009 at 3:35 PM, Scott Marlowe wrote:
> On Wed, Feb 25, 2009 at 2:32 PM, Farhan Husain wrote:
> >
> > On Wed, Feb 25, 2009 at 3:30 PM, Robert Haas
> wrote:
> >>
> >> On Wed, Feb 25, 2009 at 3:44 PM, Farhan Husain
> wrote:
> >> > Initially, it was the default value (32MB). Later
On Wed, Feb 25, 2009 at 4:32 PM, Farhan Husain wrote:
> On Wed, Feb 25, 2009 at 3:30 PM, Robert Haas wrote:
>> On Wed, Feb 25, 2009 at 3:44 PM, Farhan Husain wrote:
>> > Initially, it was the default value (32MB). Later I played with that
>> > value
>> > thinking that it might improve the perfor
On Wed, Feb 25, 2009 at 2:32 PM, Farhan Husain wrote:
>
> On Wed, Feb 25, 2009 at 3:30 PM, Robert Haas wrote:
>>
>> On Wed, Feb 25, 2009 at 3:44 PM, Farhan Husain wrote:
>> > Initially, it was the default value (32MB). Later I played with that
>> > value
>> > thinking that it might improve the p
On Wed, Feb 25, 2009 at 3:30 PM, Robert Haas wrote:
> On Wed, Feb 25, 2009 at 3:44 PM, Farhan Husain 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 tim
On Wed, Feb 25, 2009 at 3:44 PM, Farhan Husain 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 reasonabl
On Mon, Feb 23, 2009 at 1:29 PM, Sergio Lopez wrote:
> El Sat, 21 Feb 2009 21:04:49 -0500
> I've taken down the article and I'll bring up it again when I've
> collected new numbers.
Please do, this subject is very interesting.
Regards.
--
Sent via pgsql-performance mailing list (pgsql-performa
On Wed, Feb 25, 2009 at 1:52 PM, Robert Haas wrote:
> > Please note that this (1792MB) is the highest that I could set for
> work_mem.
>
> Yeah, that's almost certainly part of your problem.
>
> You need to make that number MUCH smaller. You probably want a value
> like 1MB or 5MB or maybe if yo
On Wed, Feb 25, 2009 at 12:05 PM, Farhan Husain wrote:
>
> On Wed, Feb 25, 2009 at 12:58 PM, Robert Haas wrote:
>>
>> Just start up psql and type:
>>
>> show work_mem;
>
> I did it, it does not show anything.
Did you remember the ; symbol?
> Here is what I have got from the config
> file:
>
> s
> Please note that this (1792MB) is the highest that I could set for work_mem.
Yeah, that's almost certainly part of your problem.
You need to make that number MUCH smaller. You probably want a value
like 1MB or 5MB or maybe if you have really a lot of memory 20MB.
That's insanely high.
...Rob
Most benchmarks and reviews out there are very ignorant on SSD design. I
suggest you start by reading some white papers and presentations on the
research side that are public:
(pdf) http://research.microsoft.com/pubs/63596/USENIX-08-SSD.pdf
(html)
http://www.usenix.org/events/usenix08/tech/full
On Wed, Feb 25, 2009 at 12:58 PM, Robert Haas wrote:
> Just start up psql and type:
>
> show work_mem;
>
> (You could look in the config file too I suppose.)
>
> ...Robert
>
> On Wed, Feb 25, 2009 at 1:53 PM, Farhan Husain wrote:
> >
> >
> > On Wed, Feb 25, 2009 at 12:49 PM, Robert Haas
> wrote
Just start up psql and type:
show work_mem;
(You could look in the config file too I suppose.)
...Robert
On Wed, Feb 25, 2009 at 1:53 PM, Farhan Husain wrote:
>
>
> On Wed, Feb 25, 2009 at 12:49 PM, Robert Haas wrote:
>>
>> You still haven't answered the work_mem question, and you probably
>>
On Wed, Feb 25, 2009 at 12:49 PM, Robert Haas wrote:
> You still haven't answered the work_mem question, and you probably
> want to copy the list, rather than just sending this to me.
>
> ...Robert
>
> On Wed, Feb 25, 2009 at 1:34 PM, Farhan Husain wrote:
> >
> >
> > On Tue, Feb 24, 2009 at 8:21
Hi,
I was reading a benchmark that sets out block sizes against raw IO
performance for a number of different RAID configurations involving high
end SSDs (the Mtron 7535) on a powerful RAID controller (the Areca
1680IX with 4GB RAM). See
http://jdevelopment.nl/hardware/one-dvd-per-second/
Tomasz Myrta writes:
> Does Postgres have ability to keep .dict and .affix files cached
> globally for all client sessions?
No, there's no provision for that.
> Every time I connect to test server - it takes 3 seconds to load 4MB
> dictionary when executing first FTS query.
You might consider
>You might also be interested in:
>
> http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/
>
> http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/
Thanks a lot for the pointers. I'll definitely check these out.
> It seems you have
henk de wit writes:
> Hi,
> I was reading a benchmark that sets out block sizes against raw IO performance
> for a number of different RAID configurations involving high end SSDs (the
> Mtron 7535) on a powerful RAID controller (the Areca 1680IX with 4GB RAM). See
> http://jdevelopment.nl/hardwar
Hi,
I was reading a benchmark that sets out block sizes against raw IO performance
for a number of different RAID configurations involving high end SSDs (the
Mtron 7535) on a powerful RAID controller (the Areca 1680IX with 4GB RAM). See
http://jdevelopment.nl/hardware/one-dvd-per-second/
>From
Hello
Does Postgres have ability to keep .dict and .affix files cached
globally for all client sessions?
Every time I connect to test server - it takes 3 seconds to load 4MB
dictionary when executing first FTS query.
--
Regards,
Tomasz Myrta
--
Sent via pgsql-performance mailing list (pgsq
31 matches
Mail list logo
