Wow thanks for all the help Tom and Alan. Sadly I was un-aware of the
well-known behavior. Consider it more will known now.
Fsync is off in 8.3.
I am not too worried about what was before in 8.1 since we are not going
back.
For the first example (bad behavior when I am not using transactions)
On Mon, Dec 22, 2008 at 7:27 AM, Kevin Grittner
wrote:
"Mark Wong" wrote:
>
>> The DL380 G5 is an 8 core Xeon E5405 with 32GB of
>> memory. The MSA70 is a 25-disk 15,000 RPM SAS array, currently
>> configured as a 25-disk RAID-0 array.
>
>> number of connections (250):
>
>> Moving forward,
On Monday 12 January 2009, Bill Preston
wrote:
> I had a data load that I was doing with 8.1. It involved about 250k sql
> statements that were inserts into a table with just one index. The index
> has two fields.
> With the upgrade to 8.3 that process started taking all night and 1/2 a
> day. I
Bill Preston writes:
> I've noticed some performance problems that I am guessing are WAL
> related based on my browsing around and wondered if someone had some
> suggestions for tuning the WAL settings. It could also help if someone
> just laughed at me and told me it wasn't WAL.
Consider it d
Hi Group.
Recently upgraded from 8.1 to 8.3 on RHEL 5 64-bit.
I've noticed some performance problems that I am guessing are WAL
related based on my browsing around and wondered if someone had some
suggestions for tuning the WAL settings. It could also help if someone
just laughed at me and tol
On Mon, Jan 12, 2009 at 4:55 PM, David Wilson wrote:
> On Mon, Jan 12, 2009 at 5:59 PM, Scott Marlowe
> wrote:
>> I can't figure out where my time's going to.
>
> Looks like it's going to:
>
> -> Index Scan using users_orgid_idx on users u (cost=0.00..129.52
> rows=5 width=271) (actual time=84
On Mon, Jan 12, 2009 at 5:59 PM, Scott Marlowe wrote:
> I can't figure out where my time's going to.
Looks like it's going to:
-> Index Scan using users_orgid_idx on users u (cost=0.00..129.52
rows=5 width=271) (actual time=843.825..860.638 rows=0 loops=35)
I'd guess the index/pages for users
"Scott Marlowe" writes:
> -> Index Scan using users_orgid_idx on users u (cost=0.00..129.52
> rows=5 width=271) (actual time=843.825..860.638 rows=0 loops=35)
>Index Cond: (u.orgid = j2.orgid)
>Filter: ((u.type_id < 10) AND (u.deleted = 0) AND
> ((low
Scott Marlowe wrote:
>
> OK, I've got a query that's running slow the first time, then fast.
> But I can't see where the time is really being spend on the first run.
> Query and plan attached to preserve formatting.
Often this is from caching -- the first time the system has to go to disk to
ge
On Mon, Jan 12, 2009 at 2:59 PM, Scott Marlowe wrote:
> OK, I've got a query that's running slow the first time, then fast.
> But I can't see where the time is really being spend on the first run.
> Query and plan attached to preserve formatting.
>
> The index scan and nested loop that feed the n
OK, I've got a query that's running slow the first time, then fast.
But I can't see where the time is really being spend on the first run.
Query and plan attached to preserve formatting.
The index scan and nested loop that feed the next layer up nested loop
both show very short run times. Yet th
On Monday 12 January 2009, "Scott Marlowe" wrote:
> I've found that when you do frequently query on two or more columns, a
> multi-column index is faster than bitmap scans, especially for larger
> data sets.
Very much faster, especially if you're only looking for a few dozen or
hundred rows out
On Mon, Jan 12, 2009 at 12:23 PM, Andreas Kretschmer
wrote:
> Jörg Kiegeland schrieb:
>
>> Hello,
>>
>> I created a multicolumn index on the columns c_1,..,c_n .
>> If I do use only a true subset of these columns in a SQL query, is the
>> index still efficient?
>> Or is it better to create anothe
Jörg Kiegeland schrieb:
> Hello,
>
> I created a multicolumn index on the columns c_1,..,c_n .
> If I do use only a true subset of these columns in a SQL query, is the
> index still efficient?
> Or is it better to create another multicolumn index defined on this subset?
Create several indexes
On Mon, 2009-01-12 at 18:49 +0100, Jörg Kiegeland wrote:
> Hello,
>
> I created a multicolumn index on the columns c_1,..,c_n .
> If I do use only a true subset of these columns in a SQL query, is the
> index still efficient?
> Or is it better to create another multicolumn index defined on this s
Hello,
I created a multicolumn index on the columns c_1,..,c_n .
If I do use only a true subset of these columns in a SQL query, is the
index still efficient?
Or is it better to create another multicolumn index defined on this subset?
Thanks for any comments!
--
Sent via pgsql-performance mai
On Sun, 11 Jan 2009, M. Edward (Ed) Borasky wrote:
Where you *will* have some major OS risk is with testing-level software
or "bleeding edge" Linux distros like Fedora.
I just ran "uptime" on my home machine, and it said 144 days. Debian
unstable, on no-name hardware. I guess the last time I r
Hi Scott,
as you know since the other thread, I performed some tests:
-bash-3.1$ pgbench -c 50 -t 1000
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 50
number of transactions per client: 1000
number of transactions actually processed: 5/5
18 matches
Mail list logo
