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
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
henk de wit henk53...@hotmail.com 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
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 to
Tomasz Myrta jas...@klaster.net 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
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
On Wed, Feb 25, 2009 at 12:49 PM, Robert Haas robertmh...@gmail.com 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 russ...@gmail.com 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 russ...@gmail.com wrote:
On Wed, Feb 25, 2009 at 12:49 PM, Robert Haas robertmh...@gmail.com wrote:
You still haven't answered the
On Wed, Feb 25, 2009 at 12:58 PM, Robert Haas robertmh...@gmail.com 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 russ...@gmail.com wrote:
On Wed, Feb 25, 2009 at 12:49
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)
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.
On Wed, Feb 25, 2009 at 12:05 PM, Farhan Husain russ...@gmail.com wrote:
On Wed, Feb 25, 2009 at 12:58 PM, Robert Haas robertmh...@gmail.com 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
On Wed, Feb 25, 2009 at 1:52 PM, Robert Haas robertmh...@gmail.com 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
On Mon, Feb 23, 2009 at 1:29 PM, Sergio Lopez sergio.lo...@nologin.es 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
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
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
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
On Wed, Feb 25, 2009 at 4: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
On Wed, Feb 25, 2009 at 3:35 PM, Scott Marlowe scott.marl...@gmail.comwrote:
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
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
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
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
On Wed, Feb 25, 2009 at 3:55 PM, Scott Marlowe scott.marl...@gmail.comwrote:
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
Wed, 25 Feb 2009 15:43:49 -0600 -n
Farhan Husain russ...@gmail.com í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
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
Farhan Husain russ...@gmail.com 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
On Wed, Feb 25, 2009 at 4:10 PM, Kevin Grittner kevin.gritt...@wicourts.gov
wrote:
Farhan Husain russ...@gmail.com 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,
Farhan Husain russ...@gmail.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Farhan Husain russ...@gmail.com 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
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
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
30 matches
Mail list logo
