"Tim Truman" <[EMAIL PROTECTED]> writes:
> Here is an "explain analyze" for the query that performs slowly,
This shows that the planner is exactly correct in thinking that all
the runtime is going into the seqscan on transaction:
> "Aggregate (cost=88256.32..88256.32 rows=1 width=0) (actual
> ti
Here is an "explain analyze" for the query that performs slowly, I hope this
helps unfortunately I can't reproduce the version of the query that ran
quickly and therefore can't provide and 'explain analyze' for it.
"Aggregate (cost=88256.32..88256.32 rows=1 width=0) (actual
time=55829.000..55829.
> 1. fork your import somhow to get all 4 cores running
This is already happening, albeit only 3. No improvement - it appears we
have taken the same problem, and divided it by 3. Same projected completion
time. this is really curious, to say the least.
> 2. write the code that actually does the
> My experience with that type of load process is that doing this
> row-by-row is a very expensive approach and your results bear that out.
I expected this, and had warned the client before the project started that
this is exactly where SQL underperforms.
> It is often better to write each step
> Did you think about putting the whole data into PostgreSQL using COPY in
> a nearly unprocessed manner, index it properly, and then use SQL and
> stored functions to transform the data inside the database to the
> desired result?
This is actually what we are doing. The slowness is on the row-by-
I have loaded three of the four cores by running three different versions of
the import program to import three different segments of the table to
import. The server jumps to 75% usage, with three postgresql processes
eating up 25% each., the actual client itself taking up just a few ticks.
"He
On Oct 2, 2006, at 7:31 PM, Steve Martin wrote:
Regarding, newsysviews, what is the current state, I have had a
quick look at the pgFoundry site and the last updates were 9 months
ago.
Well, the system catalogs don't change terribly often, so it's not
like a lot needs to be done. We'd hope
Hi
Thanks for you replies.
Regarding, newsysviews, what is the current state, I have had a quick
look at the pgFoundry site and the last updates were 9 months ago.
The most efficient way in the short term I can find to improve
performance for our application is to create a table from
inform
Hi, Uwcssa,
uwcssa wrote:
>
> Please unsubscribe me! Thank you!
Sorry, but we (the list members) are unable do that, we have no
adminstrative power on the list. :-(
> Also, it would be better to have a message foot saying how to unsubscribe.
List unsubscribe information is contained in t
On Sun, Oct 01, 2006 at 11:01:19PM -0400, Tom Lane wrote:
> Steve Martin <[EMAIL PROTECTED]> writes:
> > I am trying to determine if there is a way to improve the performance
> > when selecting data from the information_schema.columns view.
>
> In my experience, there isn't any single one of the
On Sat, Sep 30, 2006 at 02:55:54PM +0530, Nimesh Satam wrote:
> I am trying to vaccum one of the table using the following command:
>
> VACUUM FULL ANALYZE VERBOSE table_name;
Are you sure you want to do a vacuum full? Normally, that shouldn't be
required.
--
Jim Nasby
Please unsubscribe me! Thank you!
Also, it would be better to have a message foot saying how to unsubscribe.
Yes, my system is DEBIAN SARGE 3.0thanks,Marcelo2006/10/2, Joshua D. Drake <[EMAIL PROTECTED]>:
Marcelo Costa wrote:> Hi, to all!>> Recently i try increasing the memory values of shared buffers on one> IBM xseries 255 (Quad XEON 2.8, 8 GB RAM, 2 disk SCSI 36 GB(Raid 1), 1> Storage.
You haven't spec
Marcelo Costa wrote:
> Hi, to all!
>
> Recently i try increasing the memory values of shared buffers on one
> IBM xseries 255 (Quad XEON 2.8, 8 GB RAM, 2 disk SCSI 36 GB(Raid 1), 1
> Storage.
You haven't specified your OS so I am going to assume Linux.
> Where I start up the cluster very message
On Fri, 2006-09-29 at 11:55 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > PreallocXlogFiles() adds only a *single* xlog file, sometimes.
>
> Hm, you are right. I wonder why it's so unaggressive ... perhaps
> because under normal circumstances we soon settle into a steady
>
On Tue, 2006-08-08 at 16:42 -0400, Tom Lane wrote:
> Patrice Beliveau <[EMAIL PROTECTED]> writes:
> >>> SELECT * FROM TABLE
> >>> WHERE TABLE.COLUMN1=something
> >>> AND TABLE.COLUMN2=somethingelse
> >>> AND function(TABLE.COLUMN3,TABLE.COLUMN4) > 0;
>
> > I find out that the function process ever
On Thursday 28 September 2006 17:18, Ben wrote:
> explain select
> distinct public.album.id
> from
> public.album,public.albumjoin,public.track,umdb.node
> where
> node.dir=2811
> and albumjoin.album = public.album.id
> and public.albumjoin.track = public.track.id
>
Hi, to all!
Recently i try increasing the memory values of shared buffers on one
IBM xseries 255 (Quad XEON 2.8, 8 GB RAM, 2 disk SCSI 36 GB(Raid 1), 1
Storage.
I try change these shared memory values to use 25% of memory ram (2048
MB) and effective_cache_size to 50% (4096 MB) of memory. All thi
On Thu, 2006-08-17 at 14:33 -0400, Tom Lane wrote:
> There's a more interesting issue, which I'm afraid we do not have time
> to fix for PG 8.2. The crux of the matter is that given
>
> SELECT ...
> FROM SHEEP_FLOCK f1 JOIN
> (SELECT f.regn_no, MAX(f.transfer_date) as last_xfer_date
> F
19 matches
Mail list logo
