On 7/26/05, Roberto Germano Vieweg Neto <[EMAIL PROTECTED]> wrote:
> My application is using Firebird 1.5.2
>
> My question is:
>
> Postgre SQL will be more faster than Firebird? How much (in percent)?
>
> I need about 20% to 50% more performance at my application.
> Can I get this migratin to p
Is there a way to make the query planner consider pulling inner appends
outside joins?
Example:
natural_person inherits from person (obviously)
admpostgres3=# explain analyze select u.name, p.name from users u, person p
where p.user_id = u.id and u.name = 's_ohl';
Jens-Wolfhard Schicke <[EMAIL PROTECTED]> writes:
> Is there a way to make the query planner consider pulling inner appends
> outside joins?
Not at the moment.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you chec
Thank you all for your great input. It sure helped.
--
Husam
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jochem van
Dieten
Sent: Tuesday, July 26, 2005 2:58 AM
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] "Vacuum Full Analyze" takin
Luke,
> Well - now that I test it, it appears you are correct, temp table COPY
> bypasses WAL - thanks for pointing it out!
RIght. The problem is bypassing WAL for loading new "scratch" tables which
aren't TEMPORARY tables. We need to do this for multi-threaded ETL, since:
a) Temp tables can'
On Wed, 27 Jul 2005, Josh Berkus wrote:
> b) you can't index a temp table.
>
jurka# create temp table t (a int);
CREATE
jurka# create index myi on t(a);
CREATE
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an app
Folks,
I ran a wal_buffer test series. It appears that increasing the
wal_buffers is indeed very important for OLTP applications, potentially
resulting in as much as a 15% average increase in transaction processing.
What's interesting is that this is not just true for 8.1, it's true for
8.0
Shashi Kanth Boddula schrieb:
> Hi,
> I have one customer who is using PostgreSQL 7.4.8 on Linux . He has
> some problems with database mirroring . The details are follows.
> The customer is using Linux on which PostgreSQL 7.4.8 along with Jboss
> 3.2.3 is running . He has 2 servers , one is actin
On Wed, 2005-07-27 at 09:29 -0700, Josh Berkus wrote:
> Luke,
>
> > Well - now that I test it, it appears you are correct, temp table COPY
> > bypasses WAL - thanks for pointing it out!
>
> RIght. The problem is bypassing WAL for loading new "scratch" tables which
> aren't TEMPORARY tables. W
I had in mind the extra tables that an application sometimes needs to
operate faster. Denormalisations, pre-joined tables, pre-calculated
results, aggregated data. These are not temporary tables, just part of
the application - multi-user tables that stay across shutdown/restart.
You could al
I'm not sure how much this has been discussed on the list, but wasn't
able to find anything relevant in the archives.
The new Spamassassin is due out pretty soon. They are currently testing
3.1.0pre4. One of the things I hope to get out of this release is bayes
word stats moved to a real RDBMS.
Matt,
> After playing with various indexes and what not I simply am unable to
> make this procedure perform any better. Perhaps someone on the list can
> spot the bottleneck and reveal why this procedure isn't performing that
> well or ways to make it better.
Well, my first thought is that this
Josh Berkus writes:
> RIght. The problem is bypassing WAL for loading new "scratch" tables which
> aren't TEMPORARY tables. We need to do this for multi-threaded ETL, since:
> a) Temp tables can't be shared by several writers, and
> b) you can't index a temp table.
This may not matter given p
Josh Berkus wrote:
> Matt,
>
>
>>After playing with various indexes and what not I simply am unable to
>>make this procedure perform any better. Perhaps someone on the list can
>>spot the bottleneck and reveal why this procedure isn't performing that
>>well or ways to make it better.
>
>
> Wel
Matt,
> UPDATE bayes_vars SET
> $token_count_update
> newest_token_age = GREATEST(newest_token_age, ?),
> oldest_token_age = LEAST(oldest_token_age, ?)
> WHERE id = ?
>
>
> I think the reason why the procedure was written for postgres was
> because of the greatest and least statements perf
Josh Berkus wrote:
> Matt,
>
> Well, it might be because we don't have a built-in GREATEST or LEAST prior to
> 8.1. However, it's pretty darned easy to construct one.
I was more talking about min() and max() but yea, I think you knew where
I was going with it...
>
> Well, there's the genera
Hi all;
I have a customer who currently uses an application which had become
slow. After doing some digging, I found the slow query:
SELECT c.accno, c.description, c.link, c.category, ac.project_id,
p.projectnumber,
a.department_id, d.description AS department
FROM chart c JOIN acc_t
Matthew Schumacher <[EMAIL PROTECTED]> writes:
> After playing with various indexes and what not I simply am unable to
> make this procedure perform any better. Perhaps someone on the list can
> spot the bottleneck and reveal why this procedure isn't performing that
> well or ways to make it bette
On Wed, 2005-07-27 at 14:35 -0800, Matthew Schumacher wrote:
> I put the rest of the schema up at
> http://www.aptalaska.net/~matt.s/bayes/bayes_pg.sql in case someone
> needs to see it too.
Do you have sample data too?
--
Karim Nassar
Collaborative Computing Lab of NAU
Office: (928) 523 5868 -
19 matches
Mail list logo
