> Mark Wong <[EMAIL PROTECTED]> writes:
>> After over a year of problems (old site
>> http://developer.osdl.org/markw/postgrescvs/) I have resumed producing
>> daily results of dbt-2 against PostgreSQL CVS code with results here:
>> http://dbt.osdl.org/dbt2.
> Mark Wong <[EMAIL PROTECTED]> writes:
>> Curious, I'm still seeing the same behavior. Maybe I'll take another
>> snapshot from CVS.
>
> Hm, maybe I need to try a bit harder here. Does the "not registered"
> error happen immediately/reliably for you, or do you need to run the
> test awhile?
It
> On Tue, 2005-08-16 at 16:07 -0700, Mark Wong wrote:
>> On Tue, 16 Aug 2005 18:53:55 -0400
>> Tom Lane <[EMAIL PROTECTED]> wrote:
>>
>> > Mary Edie Meredith <[EMAIL PROTECTED]> writes:
>> > > I'm still very concerned about what I'm seeing in the oprofile:
>> > > namely: .CreateLWLocks is the seco
l.org/lab_activities/lab_projects/
Let me know if you have any questions.
--
Mark Wong - - [EMAIL PROTECTED]
Open Source Development Lab Inc - A non-profit corporation
12725 SW Millikan Way - Suite 400 - Beaverton, OR 97005
(503) 626-2455 x 32 (office)
(503) 626-2436 (fax)
http://developer.osdl.org/
On 26 Jul, To: [EMAIL PROTECTED] wrote:
> Sorry I wasn't clearer. I think I have a better idea about what's going
> on now. With the archiving enabled, it looks like the database is able
> to complete 1 transaction per database connection, but doesn't complete
> any subsequent transactions. I'm n
On 14 Jul, Simon Riggs wrote:
> PITR Patch v5_1 just posted has Point in Time Recovery working
>
> Still some rough edgesbut we really need some testers now to give
> this a try and let me know what you think.
>
> Klaus Naumann and Mark Wong are the only [non-committers] to have tried
> t
Hi Manfred,
Oopsies, fixed that. I've removed the -r flag. Thanks for catching
that.
Mark
On 6 Jul, Manfred Koizar wrote:
> Mark,
>
> I've tried to run some performance tests on your Scalable Test Platform
> but the tests failed at the build step.
>
> I guess the problem is near line 282 of
hanged for where the tables and
indexes reside.
--
Mark Wong - - [EMAIL PROTECTED]
Open Source Development Lab Inc - A non-profit corporation
12725 SW Millikan Way - Suite 400 - Beaverton, OR 97005
(503) 626-2455 x 32 (office)
(503) 626-2436 (fax)
http://developer.osdl
On 16 Jun, Bruce Momjian wrote:
> With today being June 16th, we are half-way into the one month extension
> of the feature freeze, now scheduled for July 1. Here is the status on
> the various outstanding features:
>
> Tablespaces - This has been in the queue since June 1 and should have
On 12 Feb, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> Ok, I have EXPLAIN ANALYZE results for both the power and throughput
>> tests:
>> http://developer.osdl.org/markw/dbt3-pgsql/
>
> Thanks. I just looked at Q9 and Q21, since those are the slowest
> q
On 9 Feb, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> I'll see what I can do about the "explain" and "explain analyze"
>> results. I remember in the past that someone said it would be most
>> interesting to execute the latter while the test while running, as
>> opposed to before or after a tes
On 30 Mar, Manfred Koizar wrote:
> On Mon, 29 Mar 2004 08:50:42 -0800 (PST), [EMAIL PROTECTED] wrote:
>>In this case, I've only done 1 per each combination. I've found the
>>results for this test to be reproduceable.
>
> Pardon?
I haven't repeated any runs for each combination, e.g. 1 test with
Hi Manfred,
On 27 Mar, Manfred Koizar wrote:
> Mark,
>
> how often did you run your tests? Are the results reproduceable?
In this case, I've only done 1 per each combination. I've found the
results for this test to be reproduceable.
> On Fri, 26 Mar 2004 14:00:01 -0800 (PST), [EMAIL PROTECTE
433744234471457641113642
16 KB 441244954532453629852312
32 KB 370537843886392529362362
Links to more data:
http://developer.osdl.org/markw/lvm2/blocks.html
Mark
---(e
On 26 Mar, Manfred Spraul wrote:
> [EMAIL PROTECTED] wrote:
>
>>Compare file sync methods with one 8k write:
>>(o_dsync unavailable)
>>open o_sync, write 6.270724
>>write, fdatasync13.275225
>>write, fsync, 13.359847
>>
>>
> Odd. Which fi
On 26 Mar, Bruce Momjian wrote:
> [EMAIL PROTECTED] wrote:
>> On 26 Mar, Manfred Spraul wrote:
>> > [EMAIL PROTECTED] wrote:
>> >
>> >>Compare file sync methods with one 8k write:
>> >>(o_dsync unavailable)
>> >>open o_sync, write 6.270724
>> >>write, fdatasync
ave any impact on SELECT
> performance, only insert/update/delete performance.
Ok, here are the results I have from my 4-way xeon system, a 14 disk
volume for the log and a 52 disk volume for everything else:
http://developer.osdl.org/markw/pgsql/wal_sync_method.html
7.5devel-2
On 25 Mar, Manfred Spraul wrote:
> Tom Lane wrote:
>
>>[EMAIL PROTECTED] writes:
>>
>>
>>>I could certainly do some testing if you want to see how DBT-2 does.
>>>Just tell me what to do. ;)
>>>
>>>
>>
>>Just do some runs that are identical except for the wal_sync_method
>>setting. Note that
On 18 Mar, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
>> 1) This is an OSS project. Why not just recruit a bunch of people on
>> PERFORMANCE and GENERAL to test the 4 different synch methods using real
>> databases? No test like reality, I say
>
> I agree --- that is like
http://developer.osdl.org/markw/ia64/dbt2/
I have a summary of intial results from our DBT-2 workload with
PostgreSQL 7.4.1 on a 4-way Itanium2 system with 16GB of memory and 56
drives using LVM2 and linux-2.6.3. There's readprofile
and oprofile data, but oprofile is seg faulting when
d then another test to confirm your theory. Sound good?
>
> Sure, it's only cycles ;-). I am not certain that an index on
> commitdate would help any, but it's worth trying.
http://developer.osdl.org/markw/dbt3-pgsql/70/
Those are results from a pull from CVS I did this mo
On 16 Feb, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> I ran a test with the CAST you recommended for Q4 over the weekend:
>> http://developer.osdl.org/markw/dbt3-pgsql/68/
>> But it didn't seem to have much of an affect on Q4, compared to run
>> #66. I
this, so if you care to re-sync with CVS tip you should
> find that the queries using this sort of date constraint go faster.
> (You do have indexes on all the date columns, no?)
I ran a test with the CAST you recommended for Q4 over the weekend:
http://developer.osdl.org/markw/dbt3-pgsql/68/
On 16 Feb, Dennis Haney wrote:
> [EMAIL PROTECTED] wrote:
>
>>On 12 Feb, Tom Lane wrote:
>>
>>
>>http://developer.osdl.org/markw/dbt3-pgsql/62/
>>
>>This run changes default_statistics_target to 1000 and I have p_partkey,
>>l_partkey, ps_suppkey
It's the
> original that wouldn't finish on Postgres 7.3.
Josh,
http://developer.osdl.org/markw/dbt3-pgsql/
Check out #61. I replaced the Q19 template with the one Jenny sent out.
Looks like it ran just fine. This run also has the EXPLAIN ANALYZE
results,
On 12 Feb, Josh Berkus wrote:
> Mark,
>
>> It's run #60 and the links are towards the bottom of the page under the
>> "Run log data" heading. The results from the power test is
>> "power_query.result" and "thuput_qs1.result", etc. for each stream in
>> the throughput test.
>
> I'm confused. Wer
Ok, I have EXPLAIN ANALYZE results for both the power and throughput
tests:
http://developer.osdl.org/markw/dbt3-pgsql/
It's run #60 and the links are towards the bottom of the page under the
"Run log data" heading. The results from the power test is
"power_query.res
On 9 Feb, Josh Berkus wrote:
> Mark,
>
>> Ok, I've found that the kit does capture "explain" results and I've
>> added a "Query Plans" links under the query time charts on each of the
>> pages. Um, but I did notice a couple of problems. It looks liks one of
>> the 22 queries is missing and they
On 9 Feb, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> http://developer.osdl.org/markw/dbt3-pgsql/
>
>> There's a short summary of the tests I ran over the weekend, with links
>> to detailed retults. Comparing runs 43 (7.4) and 52 (7.5devel), it
>> looks lik
ive TPC-R benchmark, we ran
>>> into a query (#19) which took several hours to complete on PostgreSQL.
http://developer.osdl.org/markw/dbt3-pgsql/
There's a short summary of the tests I ran over the weekend, with links
to detailed retults. Comparing runs 43 (7.4) and 52 (7.5devel
On 6 Feb, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> creating template1 database in /opt/pgdb/dbt2/base/1 ... ERROR: relnatts disagrees
>> with indnatts for index 16601
>
> Wow, that's a bizarre one. Are you sure you did a clean rebuild?
> I usually like to do "make distclean" before or af
e of
>> anything will help, if you guys already aren't already aware of the
>> problem.
>
> CVS tip is not broken to my knowledge. Details please?
I ran this:
$ strace -o /tmp/initdb-7.5.out initdb -D /opt/pgdb/dbt2
The files belonging to this database system will be o
On 5 Jan, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
>> 2) DEVELOP BETTER PLANS FOR "OR GROUP" QUERIES
>
>> Summary: Currently, queries with complex "or group" criteria get devolved by
>> the planner into canonical and-or filters resulting in very poor execution on
>> large data s
http://khack.osdl.org/stp/287106/
And for review, you can see intructions on how to run your own here:
http://developer.osdl.org/markw/stp_dbt2_howto.html
Mark
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
2 (office)
(503) 626-2436 (fax)
http://developer.osdl.org/markw/
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On 5 Jan, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
>> 2) DEVELOP BETTER PLANS FOR "OR GROUP" QUERIES
>
>> Summary: Currently, queries with complex "or group" criteria get devolved by
>> the planner into canonical and-or filters resulting in very poor execution on
>> large data s
Hi Manfred,
Just wanted to let you know I tried your patch-spinlock-i386 patch on
our STP (our automated test platform) 8-way systems and saw a 5.5%
improvement with Pentium III Xeons. If you want to see those results:
PostgreSQL 7.4.1:
http://khack.osdl.org/stp/285062/
PostgreSQL 7.4.1
stable release:
http://developer.osdl.org/markw/stp_dbt2_howto.html
The instructions also cover how to get oprofile annoted assembly source
in the test results. Feel free to ask any questions.
--
Mark Wong - - [EMAIL PROTECTED]
Open Source Development Lab Inc - A non-profit corporation
12725
TED]; [EMAIL PROTECTED]; pgsql-
>> [EMAIL PROTECTED]
>> Subject: more dbt-2 results hyperthreading on linux-2.6.0-test11
>>
>> Hi Nick,
>>
>> Here are the results of the comparisons I said I would do.
>>
>> no-hyperthreading:
>> http://deve
Hi Nick,
Here are the results of the comparisons I said I would do.
no-hyperthreading:
http://developer.osdl.org/markw/dbt2-pgsql/282/
- metric 2288.43
- baseline
hyperthreading:
http://developer.osdl.org/markw/dbt2-pgsql/278/
- metric 1944.42
here:
http://khack.osdl.org/stp/284353/
Thanks!
--
Mark Wong - - [EMAIL PROTECTED]
Open Source Development Lab Inc - A non-profit corporation
12725 SW Millikan Way - Suite 400 - Beaverton, OR 97005
(503) 626-2455 x 32 (office)
(503) 626-2436 (fax)
http://developer.osdl.org/markw/
On 1 Nov, Tom Lane wrote:
> Manfred Spraul <[EMAIL PROTECTED]> writes:
>> signal handlers are a process property, not a thread property - that
>> code is broken for multi-threaded apps.
>
> Yeah, that's been mentioned before, but I don't see any way around it.
> What we really want is to turn of
On 1 Nov, Tom Lane wrote:
> Manfred Spraul <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> What we really want is to turn off SIGPIPE delivery on our socket
>>> (only), but AFAIK there is no API to do that.
>>>
>> Linux has as MSG_NOSIGNAL flag for send(), but that seems to be Linux
>> specif
ofile (postgresql profile) statistics.
Results from 7.3.4:
http://developer.osdl.org/markw/dbt2-pgsql/184/
- metric 1354.58
Results from 7.4beta5
http://developer.osdl.org/markw/dbt2-pgsql/188/
- metric 1446.01
7.4beta5 offers more throughput. One significant differe
On 24 Sep, Greg Stark wrote:
> Ok, I guess I misunderstood you. These queries are taking 0.5ms - 300ms except
> for the last aggregate query which takes just over 1s.
http://developer.osdl.org/markw/dbt2-pgsql/120/
I have more data where I got the response times for each transaction
much
On 25 Sep, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> I take it PQexec() should wait until the COMMIT finishes?
>
> Yeah, it does. Where is the next iteration of the transaction coming
> from?
>
> Another thought occurred to me --- you said you have many parallel
> instances of this transact
On 25 Sep, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> I've been observing a interesting behavior with our DBT-2 workload.
>
> AFAICS the only possible explanation for this is that you aren't
> actually waiting for the first transaction to commit before you start
> the second one. What is the
On 25 Sep, Gaetano Mendola wrote:
> [EMAIL PROTECTED] wrote:
>
>> 2. SELECT d_next_o_id
>>INTO current_o_id
>>FROM district
>>WHERE d_w_id = 1
>>AND d_id = 8
>>
>> 3. UPDATE district
>>SET d_next_o_id = d_next_o_id + 1
>>WHERE d_w_id = 1
>>AND d_id = 8
>
> I don't kn
On 25 Sep, Zeugswetter Andreas SB SD wrote:
>
>> > >> > Are those response times in the right unit? 7-10s?
>> >
>> > No problem: http://developer.osdl.org/markw/misc/plana.out
>>
>> Ok, I guess I misunderstood you. These queries are taking 0
On 24 Sep, Greg Stark wrote:
> [EMAIL PROTECTED] writes:
>
>> On 22 Sep, Greg Stark wrote:
>> > Are those response times in the right unit? 7-10s?
>>
>> The plans (http://developer.osdl.org/markw/74/db/plan0.out) don't show
>> any table scans. T
On 25 Sep, Peter Eisentraut wrote:
> [EMAIL PROTECTED] writes:
>
>> This only occurs about 1% of the time. I'm not sure how else to analyze
>> the situation. Let me know if I can clarify anything or provide any
>> more information.
>
> Are you running more than one of these transactions in para
On 22 Sep, Greg Stark wrote:
>
> [EMAIL PROTECTED] writes:
>
>> http://developer.osdl.org/markw/74/
>
> Are those response times in the right unit? 7-10s?
Yeah, the database really isn't tuned at all. I've gotten some
suggestions off the list that I will be
I've been observing a interesting behavior with our DBT-2 workload. It
appears that a commit to a transaction is taking some time to occur.
I'll try to briefly describe what we're seeing. The transaction goes
something like this:
1. BEGIN
2. SELECT d_next_o_id
INTO current_o_id
FROM distr
http://developer.osdl.org/markw/74/
I had a couple of hiccups doubling the database size,
but I have results with proper linux kernel profile data now. The
increase in database size has decreased the overall performance, as
expected...
I haven't had the opportunity to try different dat
On 4 Sep, Manfred Spraul wrote:
> [EMAIL PROTECTED] wrote:
>
>>http://developer.osdl.org/markw/44/
>>
>>I threw together (kind of sloppily) a web page of the data I was
>>starting to collect for our DBT-2 workload (TPC-C derivative) on
>>PostgreSQL 7.3.4. K
On 6 Sep, Manfred Spraul wrote:
> Another question:
> Is it possible to apply patches to postgresql before a DBT-2 run, or is
> only patching the kernel supported?
The data I reported is from a test system I'm using in our lab, so I
can certainly try patches. The current state of STP only allow
On 4 Sep, Manfred Spraul wrote:
> [EMAIL PROTECTED] wrote:
>
>>http://developer.osdl.org/markw/44/
>>
>>I threw together (kind of sloppily) a web page of the data I was
>>starting to collect for our DBT-2 workload (TPC-C derivative) on
>>PostgreSQL 7.3.4. K
http://developer.osdl.org/markw/44/
I threw together (kind of sloppily) a web page of the data I was
starting to collect for our DBT-2 workload (TPC-C derivative) on
PostgreSQL 7.3.4. Keep in mind not much database tuning has been done
yet. Feel free to ask any questions.
--
Mark Wong
http://developer.osdl.org/markw/pgsql/7.3.4-1/
I used lcov to generate some fancy webpages that shows code coverage of
PostgreSQL 7.3.4 from running our DBT-2 workload (TPC-C derivative)
against it. I still have some kinks to work out of the workload, but is
this something that would interest
Suite 400 - Beaverton, OR 97005
(503)-626-2455 x 32 (office)
(503)-626-2436 (fax)
http://www.osdl.org/archive/markw/
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's d
I have been watching this thread vs non-threaded discussion and am completely with the
process-only crew for a couple reasons, but lets look at a few things:
The process vs threads benchmark which showed 160us vs 120us, only did the process
creation, not the delayed hit of the "copy on write" pag
Andrew McMillan wrote:
> mlw wrote:
> >
> > My music database has 50,000 arises and 210,000 albums. Many artists
> > have only one or 2 entries in the albums table (for the youngsters, CD
> > table ;-). About 34,000 have the integer key for "Various Artists" as
> > their artist entry, and another
62 matches
Mail list logo
