Re: [PERFORM] Performance issue using Tsearch2

2008-02-05 Thread Ansgar -59cobalt- Wiechers
On 2008-02-05 Viviane Lestic wrote: > QUERY PLAN > - > Sort (cost=2345.54..2345.58 rows=16 width=308) (actual > time=270638.774..270643.142 row

Re: [PERFORM] Saving result set of SELECT to table column

2008-01-14 Thread Ansgar -59cobalt- Wiechers
On 2008-01-14 Patric wrote: > Well I've a normalized database.. > For instance: > > create table Y ( pk, data... ); > create table Z ( pk , data...); > > create table X ( char, references Y, references Z); > > SELECT * from X; > > Now I want to make a listing of the resul

Re: [PERFORM] Curious about dead rows.

2007-11-13 Thread Ansgar -59cobalt- Wiechers
On 2007-11-13 Trevor Talbot wrote: > On 11/13/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote: >> Jean-David Beyer wrote: >>> Sorry. Most of the lists I send to have ReplyTo set, but a few do >>> not. And then I forget. >> >> If you use "reply to all", it works wonderfully in both cases. > > Then it

Re: [PERFORM] Regarding COPY command from Postgres 8.2.0

2007-09-14 Thread Ansgar -59cobalt- Wiechers
On 2007-09-14 soni de wrote: > In Postgres 7.2.4, COPY command is working fine even if tables have 6 > fields but we are copying only 5 fields from the file > > But in Postgres 8.2.0, if table has 6 fields and we need to copy data > for 5 fields only, then we need to specify the column names too i

Re: [PERFORM] Performance on 8CPU's and 32GB of RAM

2007-09-05 Thread Ansgar -59cobalt- Wiechers
On 2007-09-05 Scott Marlowe wrote: > On 9/5/07, Ansgar -59cobalt- Wiechers <[EMAIL PROTECTED]> wrote: >> On 2007-09-05 Scott Marlowe wrote: >>> On 9/5/07, Ansgar -59cobalt- Wiechers <[EMAIL PROTECTED]> wrote: >>>> On 2007-09-05 Scott Marlowe wrote: >

Re: [PERFORM] Performance on 8CPU's and 32GB of RAM

2007-09-05 Thread Ansgar -59cobalt- Wiechers
On 2007-09-05 Scott Marlowe wrote: > On 9/5/07, Ansgar -59cobalt- Wiechers <[EMAIL PROTECTED]> wrote: >> On 2007-09-05 Scott Marlowe wrote: >>> And there's the issue that with windows / NTFS that when one process >>> opens a file for read, it locks it for

Re: [PERFORM] Performance on 8CPU's and 32GB of RAM

2007-09-05 Thread Ansgar -59cobalt- Wiechers
On 2007-09-05 Scott Marlowe wrote: > And there's the issue that with windows / NTFS that when one process > opens a file for read, it locks it for all other users. This means > that things like virus scanners can cause odd, unpredictable failures > of your database. Uh... what? Locking isn't done

Re: [PERFORM] index over timestamp not being used

2007-07-25 Thread Ansgar -59cobalt- Wiechers
On 2007-07-25 Mario Weilguni wrote: > Am Dienstag 24 Juli 2007 schrieb Tom Lane: >>> I thought the to_char/to_date/to_timestamp functions were intented >>> for this purposes >> >> No, they're intended for dealing with wacky formats that the regular >> input/output routines can't understand or produ

Re: [PERFORM] Database Statistics???

2007-07-13 Thread Ansgar -59cobalt- Wiechers
On 2007-07-13 smiley2211 wrote: > I am a bit confused...I have a database which was performing very > POORLY selecting from a view (posted earlier) on one server but > extremely fast on another server... EXPLAIN ANALYZE'ing the query will show you the planner's estimates. The query plans should gi

Re: [PERFORM] test / live environment, major performance difference

2007-06-11 Thread Ansgar -59cobalt- Wiechers
On 2007-06-11 Christo Du Preez wrote: > I really hope someone can shed some light on my problem. I'm not sure > if this is a posgres or potgis issue. > > Anyway, we have 2 development laptops and one live server, somehow I > managed to get the same query to perform very well om my laptop, but > on

Re: [PERFORM] Equivalents in PostgreSQL of MySQL's "ENGINE=MEMORY" "MAX_ROWS=1000"

2007-04-04 Thread Ansgar -59cobalt- Wiechers
On 2007-04-04 Arnau wrote: > Josh Berkus wrote: >>> Is there anything similar in PostgreSQL? The idea behind this is how >>> I can do in PostgreSQL to have tables where I can query on them very >>> often something like every few seconds and get results very fast >>> without overloading the postmast