The option with
T1: A B C and T2 A D (to avoid the updates)
works very well with a simple query
Insert into T2 (A, D)
select A, functionToGetD from T1 left join T2 on T1.A = T2.A
where T2.A is null
The above gives me the new records for those where D was not filled yet.
Since they are all new
Thanks again everyone for the excellent suggestions.
I looked into IO::Reactor, but after a few hours of fiddling decided I was
getting the kind of performance I wanted from using a slightly more than
modest number of threads and decided(due to dev timelines) to come back to
patching the SNMP libr
> Bill of Materials Traversal ( ~ 62k records).
>
> ISAM* pg 8.0 pg 8.1 devel delta 8.0->8.1
> running time 63 sec 90 secs71 secs21%
> cpu load 17%45%32%29%
> loadsecs** 10.71 40.5 22.72 44%
> recs/sec
Hello,
I am running PostgreSQL 8.0.x on Solaris 10 AMD64. My Tablesize for this
test is about 80G. When I run a query on a column which is not indexed, I
get a full table scan query and that's what I am testing right now. (I am
artificially creating that scenario to improve that corner case)
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> One thing that might interest you is that the penalty in 8.1 for
> stats_command_string=true in this type of access pattern is very high: I
> was experimenting to see if the new cpu efficiency gave me enough of a
> budget to start using this. This mor
On Sun, 2005-08-21 at 16:13 -0400, Ron wrote:
> At 10:54 AM 8/21/2005, Jeremiah Jahn wrote:
> >On Sat, 2005-08-20 at 21:32 -0500, John A Meinel wrote:
> > > Ron wrote:
> > >
> > > Well, since you can get a read of the RAID at 150MB/s, that means that
> > > it is actual I/O speed. It may not be cach
Ron wrote:
PERC4eDC-PCI Express, 128MB Cache, 2-External Channels
Looks like they are using the LSI Logic MegaRAID SCSI 320-2E
controller. IIUC, you have 2 of these, each with 2 external channels?
A lot of people have mentioned Dell's versions of the LSI cards can be
WAY slower than the on
"Jignesh Shah" <[EMAIL PROTECTED]> writes:
> Running a script (available on my blog) I find the following top 5 functions
> where it spends most time during a 10 second run of the script
It's pretty risky to draw conclusions from only 10 seconds' worth of
gprof data --- that's only 1000 samples t
Tom,
On 8/22/05 8:41 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
>> MemoryContextSwitchTo and LockBuffer itself takes 15% of the total time of
>> the query. I was expecting "read" to be the slowest part (biggest component)
>> but it was way down in the 0.4% level.
>
> You do know that gprof counts
> That seems quite peculiar; AFAICS the pgstat code shouldn't be any
> slower than before. At first I thought it might be because we'd
> increased PGSTAT_ACTIVITY_SIZE, but actually that happened before
> 8.0 release, so it shouldn't be a factor in this comparison.
Just FYI the last time I looked
On Sat, 20 Aug 2005, John Mendenhall wrote:
> I need to improve the performance for the following
> query.
I have run the same query in the same database under
different schemas. Each schema is pretty much the same
tables and indices. One has an extra backup table and
an extra index which are n
Jignesh,
> Also is there any way to optimize LockBuffer?
Yes, test on 8.1. The buffer manager was re-written for 8.1. You should
see a decrease in both LockBuffer and context switch activity.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of
John Mendenhall <[EMAIL PROTECTED]> writes:
> The issue is the query plan is different, and thus,
> not up to the performance we need.
No, the issue is that you've got eight times as much data in the
production server; so it's hardly surprising that it takes about
eight times longer.
The producti
Tom,
> No, the issue is that you've got eight times as much data in the
> production server; so it's hardly surprising that it takes about
> eight times longer.
>
> The production query is spending most of its time on the subplan
> attached to the contacts table:
>
> > -> I
Hi Tom,
Like I mentioned I am using DTrace on Solaris 10 x64 and not gprof.
DTrace is not based on sampling but actual entry/exit point. Ofcourse my 10
second profile is just a sample that I can assure you is representative of
the query since it is a very simple query that does simple table sc
Jignesh Shah wrote:
Now the question is why there are so many calls to MemoryContextSwitchTo
in a single SELECT query command? Can it be minimized?
I agree with Tom -- if profiling indicates that MemoryContextSwitchTo()
is the bottleneck, I would be suspicious that your profiling setup is
mis
On Tue, Aug 16, 2005 at 09:29:32AM +0200, Sebastian Hennebrueder wrote:
> Hello,
>
> I would like to test the performance of my Java/PostgreSQL applications
> especially when making full text searches.
> For this I am looking for a database with 50 to 300 MB having text fields.
> e.g. A table with
RRS (http://rrs.decibel.org) might be of use in this case.
On Tue, Aug 16, 2005 at 01:59:53PM -0400, Alex Turner wrote:
> Are you calculating aggregates, and if so, how are you doing it (I ask
> the question from experience of a similar application where I found
> that my aggregating PGPLSQL trigg
John Mendenhall <[EMAIL PROTECTED]> writes:
> Would it be best to attempt to rewrite it for IN?
> Or, should we try to tie it in with a join?
Couldn't say without a deeper understanding of what you're trying to
accomplish.
> BTW, what does the Materialize query plan element mean?
Means "run the
I am looking for the latest pgbench and documentation.
If someone know where I can locate them it would save a lot of search time.
Thanks
Philip Pinkerton
TPC-C Benchmarks Sybase
Independant Consultant
Rio de Janeiro, RJ, Brazil 22031-010
---(end of broadcast)---
Hello all,
what are unused item pointers and how do I get rid of them?
We have a fairly large table which is vacuumed daily and reindexed every
weekend.
NFO: vacuuming "public.tbltimeseries"
INFO: index "idx_timeseries" now contains 26165807 row versions in
151713 pages
DETAIL: 8610108 inde
Alan Stange <[EMAIL PROTECTED]> writes:
> INFO: "tbltimeseries": found 8610108 removable, 26165807 nonremovable
> row versions in 5744789 pages
> DETAIL: 0 dead row versions cannot be removed yet.
> There were 23635 unused item pointers.
> 0 pages are entirely empty.
The item pointers themsel
Phillip,
> I am looking for the latest pgbench and documentation.
Currently they are packaged with the PostgreSQL source code.
However, if you're looking for a serious benchmark, may I suggest OSDL's DBT2?
It's substantially similar to TPC-C.
http://sourceforge.net/projects/osdldbt
What's y
On Mon, 2005-08-22 at 22:51 -0400, Alan Stange wrote:
> Hello all,
>
> what are unused item pointers and how do I get rid of them?
>
> We have a fairly large table which is vacuumed daily and reindexed every
> weekend.
> as you can see we have 235M unused item pointers in the main table and a
24 matches
Mail list logo
