Re: [SQL] INTERSECT / where id IN (etc..)

> Greetings. > > I was wondering if somone out there could shed some light on a query > performance issie I have. I have a large lookup table that I query > with nested selects to gain the INTERSECT result from. > > the bigger this table gets the slower the performance. > > 1. is creating a te

Re: [SQL] sort / limit / range problem

> Hi folks, > > I've got a glossary table that I'm trying to render to HTML. > However, I've got a problem when using order by and limit. Below > is an example of a psql session showing my problem. Anyone got any > reasons why the last select misses 'Driver'? > Everything is ok. Without o

[SQL] sort / limit / range problem

Hi folks, I've got a glossary table that I'm trying to render to HTML. However, I've got a problem when using order by and limit. Below is an example of a psql session showing my problem. Anyone got any reasons why the last select misses 'Driver'? nymr=# select glterm from glossary where g

Re: [SQL] DELETE FROM A BLACK LIST

On Wed, 5 Mar 2003 [EMAIL PROTECTED] wrote: > > Hi all, > I have a Blacklist table containing about 1000 ID to delete from another > table (T1 about 1440294 records) > If i use the SQL > > DELETE FROM T1 WHERE T1.ID IN (SELECT BLACKLIST.ID FROM BLACKLIST) > > the operation is very slow . > > T

[SQL] DELETE FROM A BLACK LIST

Hi all, I have a Blacklist table containing about 1000 ID to delete from another table (T1 about 1440294 records) If i use the SQL DELETE FROM T1 WHERE T1.ID IN (SELECT BLACKLIST.ID FROM BLACKLIST) the operation is very slow . There is a faster way to do the same operation?? Thanks Luca

Re: [SQL] Sorting by NULL values

On Tue, 2003-03-04 at 15:13, Stephan Szabo wrote: > On Tue, 4 Mar 2003, Ian Burrell wrote: > > > I am doing a query where I need to sort by a column that may be NULL > > because it is coming from an OUTER JOIN. I noticed a difference between > > PostgreSQL and other databases about where NULLs sh

Re: [SQL] Insert multiple Rows

> > If you use a 'prepared' insert within a transaction, would that speed things > up - maybe by defering index updates? > I doubt it. From: Neil Conway <[EMAIL PROTECTED]> ... I'd suspect that for most INSERT queries, the parsing/rewriting/planning stages are relatively inexpensive, and the bulk