On 10/18/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
On Tue, Oct 17, 2006 at 12:51:19PM -0400, Merlin Moncure wrote:
> so, imo alexander is correct:
> contacto varchar(255)
>
> ...is a false constraint, why exactly 255? is that were the dart landed?
BTW, if we get variable-length varlena headers
On Tue, Oct 17, 2006 at 12:25:39PM +0200, Ruben Rubio wrote:
> 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
On Tue, Oct 17, 2006 at 12:51:19PM -0400, Merlin Moncure wrote:
> so, imo alexander is correct:
> contacto varchar(255)
>
> ...is a false constraint, why exactly 255? is that were the dart landed?
BTW, if we get variable-length varlena headers at some point, then
setting certain limits might make
On Wed, Oct 18, 2006 at 11:31:44AM +0200, Mario Weilguni wrote:
> It's not a bad idea. Usually I use postal codes with 25 chars, and never had
> any problem. With text, the limit would be ~1 GB. No matter how much testing
> in the application happens, the varchar(25) as last resort is a good idea
Mario Weilguni wrote:
  contacto varchar(255),
  fuente varchar(512),
  prefijopais varchar(10)
Instead, use:
  contacto text,
  fuente text,
  prefijopais text
See the PostgreSQL manual for an explanation of varchar vs. text.
Enforcing length constraints with varchar(xyz
Am Dienstag, 17. Oktober 2006 17:50 schrieb Alexander Staubo:
> On Oct 17, 2006, at 17:29 , Mario Weilguni wrote:
> >
> > Enforcing length constraints with varchar(xyz) is good database
> > design, not a
> > bad one. Using text everywhere might be tempting because it works,
> > but it's
> > not a g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> so, imo alexander is correct:
>> contacto varchar(255)
Why do we have limits on this, for example?
contacto varchar(255)
1) First of all, this is a web application. People use to enter really
strange thinks there, and a lot of rubbish. So, as s
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
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
-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
-Original Message-
> From: [EMAIL PROTECTED] on behalf of Ruben Rubio
> Sent: Tue 10/17/2006 2:05 AM
> To: pgsql-performance@postgresql.org
> Cc:
> Subject: [PERFORM] Optimization of this SQL sentence
>
> This SQL sentence is very simple. I need to get better
> From: [EMAIL PROTECTED] on behalf of Ruben Rubio
> Sent: Tue 10/17/2006 2:05 AM
> To: pgsql-performance@postgresql.org
> Cc:
> Subject: [PERFORM] Optimization of this SQL sentence
>
> This SQL sentence is very simple. I need to get better results. I have
> tried s
ssage-
From: [EMAIL PROTECTED] on behalf of Ruben Rubio
Sent: Tue 10/17/2006 2:05 AM
To: pgsql-performance@postgresql.org
Cc:
Subject:[PERFORM] Optimization of this SQL sentence
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This SQL sentence is very simple. I need to get better re
-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
26 matches
Mail list logo
