"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 bette
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 = c
Robert Treat <[EMAIL PROTECTED]> writes:
> When it happens it tends to look something like this:
> http://archives.postgresql.org/pgsql-performance/2006-01/msg00154.php
> Funny that for all the people who claim that improving the planner should be
> the primary goal that no one ever took interest
Alexander Staubo wrote:
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 Post
On Friday 13 October 2006 12:46, Gregory Stark wrote:
> Josh Berkus 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 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,
> -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, R
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 = ctrl.obj_id and events.event_id > ?::bigint order by
events.e
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 us
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 client
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 ha
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 @ http
[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 v
[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
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:
>
> c
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,
> prefij
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 constrain
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 apo
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 peop
On 10/17/06, soni de <[EMAIL PROTECTED]> wrote:
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?
Can anybody help us regarding above query?
Assume you have a table:
CREATE TABLE
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 thi
Hello,
I was going through the Performance Enhancements of 8.1.0, in that I have read "Bitmap Scan"
"Bitmap Scan: indexes will be dynamically converted to bitmaps in memory when appropriate, giving up to twenty times faster index performance on complex queries against very large tables. This
-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 t
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 quicke
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 fic
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, idstatu
-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
-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),
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-
Fro
-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 ids
30 matches
Mail list logo
