On 05/27/09 22:00, Josh Berkus wrote:
Andy,
I have a Sun blade 1000 that's just collecting dust now days. I was
wondering if there were any pg-hackers that could find use for it.
Its dual UltraSPARC III 750 (I think) and has two 36? gig fiber channel
scsi disks.
It weighs a ton.
I'd be ha
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
While most cases were dead even or a modest improvement, his dbt-2 results
suggest a 15-20% regression in 8.4. Changing the default_statistics_taget
to 100 was responsible for about 80% of that regression.
Simon Riggs wrote:
On Thu, 2009-05-14 at 16:21 -0700, Josh Berkus wrote:
So we can optimize away the scan through the procarray by doing two "if"
tests, one outside of the lock, one inside. In normal running, both will
be optimized away, though in read-only periods we would avoid much work
On 04/08/09 13:10, Josh Berkus wrote:
On 4/8/09 9:44 AM, Tom Lane wrote:
Josh Berkus writes:
What about seq scans?
If the kernel can't read-ahead a seqscan by itself, it's unlikely to
be smart enough to be helped by posix_fadvise ... or at least so I
would think. Do you have reason to thi
Josh Berkus wrote:
Heikki,
Ideally, of course, there would be no wal_buffers setting, and WAL
buffers would be allocated from shared_buffers pool on demand...
+1
--Josh
+1
-Jignesh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
Tom Lane wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
This seems rather crazy, and you haven't actually given a single
convincing use-case.
One area that I find it useful is where it will be useful is in
ProcArrayEndTran
Tom Lane wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
New Lock Mode Proposed: LW_EX_OWNER (input on better name will be
appreciated).
This seems rather crazy, and you haven't actually given a single
convincing use-case. Shouldn't you be trying
Currently there are two modes of LWLock : SHARED and EXCLUSIVE
Mostly you need to have EXCLUSIVE lock mode to make any changes, add,
delete and SHARED if you are just reading it. Multiple backends can
grab SHARED mode simultaneously while only one Backend can grab
EXCLUSIVE at a time. There a
Simon Riggs wrote:
Some other problems I see with GUCs
* It's not possible to set one parameter depending upon the setting of
another.
To me this is more critical.. Most people I have seen will increase one
or few but not all parameters related to memory which can result in loss
of per
Tom Lane wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
Are there any head fixes proposed for it?
It's been fixed in CVS for a month. We just haven't pushed a release yet.
Let me try it out and see what I find out in my EAStress workload.
Rega
Are there any head fixes proposed for it?
I am seeing some scaling problems with EAStress which uses JDBC with
8.3.0 and this one could be the reason why I am seeing some problems.. I
will be happy to try it out and report on it.. The setup is ready right
now if someone can point me to a patch
Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
This is a tangent but are these actual Postgres processes? What's the logic
behind trying to run a 1,000 processes on a box with 16 cpus?
We should certainly be careful about trying to eliminate contention in
this scenario at
Last try for the script/results (truncating less significant portions of
output which are too big)
Staale Smedseng wrote:
her locks should have been output correctly, however.
But as Tom pointed out, the dynamic locks were not in the equation. So
now we're measuring all lock waits instead o
I dont think my earlier message got through..
We use separate lookup tables for 825 and 83 based on the respective
lwlock.h for that version.
-Jignesh
Simon Riggs wrote:
On Thu, 2008-02-07 at 16:29 +0100, Staale Smedseng wrote:
On Wed, 2008-02-06 at 19:55, Tom Lane wrote:
I am wo
setting) but the constant load which is in the range of about
2-2.5MB/sec which is not low but my load is high.
In my current run I do have async wal on with wal_writer_delay=100ms and
commit_delay off.
-Jignesh
Heikki Linnakangas wrote:
Jignesh K. Shah wrote:
Since its really writes that I
can try vacuuming that table before it starts the run to see it can
avoid that..
-Jignesh
Tom Lane wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
So from the PostgreSQL view things are doing fine based on outputs: I
need to figure out the Solaris view on it now.
be related to autovacuum happening also?
Regards,
Jignesh
Tom Lane wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
I will turn on checkpoint_logging to get more idea as Heikki suggested
Did you find out anything?
Did this happen on every checkpoint, or only some of
I am running EAStress workload.. which doesnt do manual checkpoints as
far as I know..
I will turn on checkpoint_logging to get more idea as Heikki suggested
thanks.
-Jignesh
Tom Lane wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
I am running tests with PG8.3b2 on
Hello,
I am running tests with PG8.3b2 on Solaris 10 8/07 and I still see IO
flood when checkpoint happens.
I have tried increasing the bg_lru_multiplier from 2 to 5 from default
but I dont see any more writes by bgwriter happening than my previous
test which used the default.
Then I tried i
ly better than the default ..
(Plus the risk of loosing data is reduced from 600ms to 300ms)
Thanks.
Regards,
Jignesh
Tom Lane wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
So the ratio of reads vs writes to clog files is pretty huge..
It looks to me that
-2753028252512 27
#
So the ratio of reads vs writes to clog files is pretty huge..
-Jignesh
Jignesh K. Shah wrote:
Tom,
Here is what I did:
I started aggregating all read information:
First I also had added group by pid(arg0,arg1, pid) and the counts
were all coming as
sive 15
Lock Id Combined Time (ns)
WALInsertLock55243
ProcArrayLock 69700140
#
What will help you find out why it is reading the same page again?
-Jignesh
Jignesh K. Shah wrote:
I agree with Tom.. somehow I think increasing
I agree with Tom.. somehow I think increasing NUM_CLOG_BUFFERS is just
avoiding the symptom to a later value.. I promise to look more into it
before making any recommendations to increase NUM_CLOG_BUFFERs.
Because though "iGen" showed improvements in that area by increasing
num_clog_buffer
The problem I saw was first highlighted by EAStress runs with PostgreSQL
on Solaris with 120-150 users. I just replicated that via my smaller
internal benchmark that we use here to recreate that problem.
EAStress should be just fine to highlight it.. Just put pg_clog on
O_DIRECT or something s
Hi George,
I have seen the 4M/sec problem first actually during an EAStress type
run with only 150 connections.
I will try to do more testing today that Tom has requested.
Regards,
Jignesh
Gregory Stark wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
CLOG data
Update on my testing 8.3beta1 on Solaris.
* CLOG reads
* Asynchronous Commit benefit
* Hot CPU Utilization
Regards,
Jignesh
__Background_:_
We were using PostgreSQL 8.3beta1 testing on our latest Sun SPARC
Enterprise T5220 Server using Solaris 10 8/07 and Sun Fire X4200 using
Solaris 10 8/07.
Just FYI:
I took the latest snapshot CATALOG_VERSION_NO 200707251 and function
quote_literal throws an error:
# select quote_literal(1);
2007-08-20 18:50:17 PDT ERROR: function quote_literal(integer) does not
exist at character 8
2007-08-20 18:50:17 PDT HINT: No function matches the given
I dont think we solved this.. But I think the way to put -m64 should be same as in Linux and Solaris
and not different.
Thanks.
Regards,
Jignesh
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Am Mittwoch, 17. Januar 2007 17:12 schrieb Tom Lane:
"Jignesh K. Sh
I guess that's what CFLAGS
is for..
Regards,
Jignesh
Tom Lane wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
simple if I use -m64 for 64 bit then all end binaries are generated 64-bit and the shared libraries
are generated 32-bit and the compilation fails (ONLY ON SO
properly to it and generates shared
libraries 64-bit and the compile continues..
I just tested it out.
-Jignesh
Tom Lane wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
It should be
LINK.shared = $(COMPILER) -shared
Why? What's the difference, and why
Hello All,
When I compile with gcc on Solaris with -m64 flags, all shared lbiraries fail.
Can someone fix the following in Makefile.shlib
ifeq ($(PORTNAME), solaris)
ifeq ($(GCC), yes)
LINK.shared = $(CC) -shared
else
LINK.shared = $(CC) -G $(CFLAGS)# CFLAGS add
I have seen similar performance as Josh and my reasoning is as follows:
* WAL is the biggest bottleneck with its default size of 16MB. Many
people hate to recompile the code to change its default, and
increasing checkpoint segments help but still there is lot of overhead
in the rotation of W
32 matches
Mail list logo
