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 postgresql
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 checked
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't
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
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
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 acting as
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. We need to
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
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 is
Josh Berkus josh@agliodbs.com 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
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.
Well, my first
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 performing
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 general
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
15 matches
Mail list logo
