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
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
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
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
Jörg Kiegeland kiegel...@ikv.de 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
On Mon, Jan 12, 2009 at 12:23 PM, Andreas Kretschmer
akretsch...@spamfence.net wrote:
Jörg Kiegeland kiegel...@ikv.de 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
On Monday 12 January 2009, Scott Marlowe scott.marl...@gmail.com 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
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
On Mon, Jan 12, 2009 at 2:59 PM, Scott Marlowe scott.marl...@gmail.com 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
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
get
Scott Marlowe scott.marl...@gmail.com 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 =
On Mon, Jan 12, 2009 at 5:59 PM, Scott Marlowe scott.marl...@gmail.com 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
On Mon, Jan 12, 2009 at 4:55 PM, David Wilson david.t.wil...@gmail.com wrote:
On Mon, Jan 12, 2009 at 5:59 PM, Scott Marlowe scott.marl...@gmail.com
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
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
Bill Preston billpres...@crownepointe.net 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
On Monday 12 January 2009, Bill Preston billpres...@crownepointe.net
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
On Mon, Dec 22, 2008 at 7:27 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Mark Wong mark...@gmail.com 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
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
18 matches
Mail list logo
