Sorry, I didn'tpoint it out because an earlier post included the query with
documentation - that post got lost... or at least *I* can't see it.
The other half of the union renders the facilities that DO have addresses,
and because of the performance problem (which I have finally sorted out by
you have a two part part key on facility(country code, postal code),
right?
Well, I'm glad you pointed it out, because I THOUGhT I had created it, but
apparently I haven't -- I only noticed that it was missing after I listed
all the other indexes. Looks like this query is one of the victims
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This SQL sentence is very simple. I need to get better results. I have
tried some posibilities and I didn't get good results.
SELECT max(idcomment)
FROM ficha vf
INNER JOIN comment c ON (vf.idficha=c.idfile AND (idestado=3 OR
idestado=4))
WHERE
Off hanbd I can't recommend anything, bur perhaps you could post the details of
the tables (columns, indexes),and some info on what version of postgres you are
using.
Are the tables recently analyzed ? How many rows in them ?
Greg Williamson
DBA
GlobeXplorer LLC
-Original Message-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Indexes in comment
Comment rows: 17.250
CREATE INDEX usuariofichaoncommnet
ON comment
USING btree
(idusuarioficha);
Comment structure:
CREATE TABLE comment
(
idcomment int4 NOT NULL DEFAULT
nextval('comment_idcomment_seq'::regclass),
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If just just realized that is a litlle faster (15% faster) with this:
CREATE INDEX idx_statustype
ON comment USING btree (idstatus, ctype);
Any other ideas?
Gregory S. Williamson escribió:
Off hanbd I can't recommend anything, bur perhaps
am Tue, dem 17.10.2006, um 11:33:18 +0200 mailte Ruben Rubio folgendes:
SELECT max(idcomment)
FROM ficha vf
INNER JOIN comment c ON (vf.idficha=c.idfile AND (idestado=3 OR
idestado=4))
WHERE idstatus=3
AND ctype=1
check for indexes on vf.idficha, c.idfile, idstatus and ctype.
On Oct 17, 2006, at 11:33 , Ruben Rubio wrote:
CREATE TABLE comment
(
idcomment int4 NOT NULL DEFAULT
nextval('comment_idcomment_seq'::regclass),
[snip 28 columns]
CONSTRAINT comment_pkey PRIMARY KEY (idcomment)
)
Ficha structure:
No indexes in ficha
Ficha rows: 17.850
CREATE TABLE
You could try rewriting the query like this:
SELECT MAX(idcomment)
FROM comment c
WHERE idstatus=3 AND ctype=1
AND EXISTS (SELECT 1 FROM ficha vf WHERE idestado IN ('3', '4') AND
vf.idficha = c.idfile);
The planner can then try a backward scan on the comment_pkey index,
which should be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi to everyone,
First of all I have to say that I now the database is not ok. There was
a people before me that didn't do the thinks right. I would like to
normalize the database, but it takes too much time (there is is hundred
of SQLs to change and
am Tue, dem 17.10.2006, um 17:09:29 +0530 mailte soni de folgendes:
I didn't understand the Bitmap Scan and the sentence indexes will be
dynamically converted to bitmaps in memory. What does mean by Bitmap Scan
in
database?
For instance, you have a large table with 5 indexes on this and a
On 10/17/06, soni de [EMAIL PROTECTED] wrote:
I
didn't understand theBitmap Scan andthe sentence indexes
will be dynamically converted to bitmaps in memory. What does mean by
Bitmap Scan in database?
Can anybody help us regarding above query?
Assume you have a table:
CREATE TABLE foo (
These tables are particularly egregious examples of ignorant database
design. You need to understand the relational model
This email is a *particularly* egregious example of rudeness. You owe Mr.
Staubo, and the Postgress community, an apology.
There is absolutely no reason to insult
On Oct 17, 2006, at 17:10 , Craig A. James wrote:
These tables are particularly egregious examples of ignorant
database design. You need to understand the relational model
This email is a *particularly* egregious example of rudeness. You
owe Mr. Staubo, and the Postgress community, an
On Oct 17, 2006, at 17:29 , Mario Weilguni wrote:
Am Dienstag, 17. Oktober 2006 11:52 schrieb Alexander Staubo:
Lastly, note that in PostgreSQL these length declarations are not
necessary:
contacto varchar(255),
fuente varchar(512),
prefijopais varchar(10)
Enforcing length
Am Dienstag, 17. Oktober 2006 11:52 schrieb Alexander Staubo:
Lastly, note that in PostgreSQL these length declarations are not
necessary:
contacto varchar(255),
fuente varchar(512),
prefijopais varchar(10)
Instead, use:
contacto text,
fuente text,
prefijopais text
On 10/17/06, Mario Weilguni [EMAIL PROTECTED] wrote:
Am Dienstag, 17. Oktober 2006 11:52 schrieb Alexander Staubo:
Lastly, note that in PostgreSQL these length declarations are not
necessary:
contacto varchar(255),
fuente varchar(512),
prefijopais varchar(10)
Instead, use:
contacto
[EMAIL PROTECTED] (Merlin Moncure) writes:
On 10/17/06, Mario Weilguni [EMAIL PROTECTED] wrote:
Am Dienstag, 17. Oktober 2006 11:52 schrieb Alexander Staubo:
Lastly, note that in PostgreSQL these length declarations are not
necessary:
contacto varchar(255),
fuente varchar(512),
[EMAIL PROTECTED] (Alexander Staubo) writes:
On Oct 17, 2006, at 17:29 , Mario Weilguni wrote:
Am Dienstag, 17. Oktober 2006 11:52 schrieb Alexander Staubo:
Lastly, note that in PostgreSQL these length declarations are not
necessary:
contacto varchar(255),
fuente varchar(512),
Chris Browne wrote:
In the case of a zip code? Sure. US zip codes are integer values
either 5 or 9 characters long.
So your app will only work in the US?
And only for US companies that only have US clients?
Sorry had to dig at that ;-P
--
Shane Ambler
[EMAIL PROTECTED]
Get Sheeky @
The world rejoiced as [EMAIL PROTECTED] (Shane Ambler) wrote:
Chris Browne wrote:
In the case of a zip code? Sure. US zip codes are integer values
either 5 or 9 characters long.
So your app will only work in the US?
And only for US companies that only have US clients?
Sorry had to dig
Christopher Browne wrote:
The world rejoiced as [EMAIL PROTECTED] (Shane Ambler) wrote:
Chris Browne wrote:
In the case of a zip code? Sure. US zip codes are integer values
either 5 or 9 characters long.
So your app will only work in the US?
And only for US companies that only have US
Hi
We are facing performance problems in postgres while executing a query. When I
execute this query on the server it takes 5-10 seconds. Also I get good
performance while executing this query from my code in java with the hard codes
values. I face severe performance problems when I run it
-Original Message-
From: [EMAIL PROTECTED]
[mailto:pgsql-performance-
[EMAIL PROTECTED] On Behalf Of Merlin Moncure
Sent: Tuesday, October 17, 2006 4:29 PM
To: Rohit_Behl
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Jdbc/postgres performance
On 10/17/06,
On Thursday 12 October 2006 12:40, Bucky Jordan wrote:
What is it about hinting that makes it so easily breakable with new
versions? I don't have any experience with Oracle, so I'm not sure how
they screwed logic like this up.
I don't have a ton of experience with oracle either, mostly
On Friday 13 October 2006 12:46, Gregory Stark wrote:
Josh Berkus josh@agliodbs.com writes:
I actually think the way to attack this issue is to discuss the kinds
of errors the planner makes, and what tweaks we could do to correct
them. Here's the ones I'm aware of:
-- Incorrect
On 10/18/06, Bucky Jordan [EMAIL PROTECTED] wrote:
On 10/17/06, Rohit_Behl [EMAIL PROTECTED] wrote:
Select events.event_id, ctrl.real_name, events.tsds, events.value,
events.lds, events.correction, ctrl.type, ctrl.freq from table events,
iso_midw_control ctrl where events.obj_id =
Merlin Moncure [EMAIL PROTECTED] writes:
this is not really a jdbc issue, just a practical problem with
prepared statements...
Specifically, that the OP is running a 7.4 backend, which was our
first venture into prepared parameterized statements. PG 8.1 will
do better, 8.2 should do better
28 matches
Mail list logo
