Re: [PERFORM] Advise about how to delete entries

Hi all, > > COPY FROM a file with all the ID's to delete, into a temporary table, and do a joined delete to your main table (thus, only one query). I already did this, but I don't have idea about how to do this join, could you give me a hint ;-) ? Thank you very much -- Arnau

[PERFORM] Query slow after VACUUM ANALYZE

Hi all I'm having a strange problem with a query which looks like this: SELECT id FROM orders WHERE id NOT IN (SELECT order_id FROM orders_items); The id fields are varchars (32), both indexed. The number of rows in the tables are about 6. Now, the really strange part is if I delete all dat

Re: [PERFORM] Poor SQL performance

Place 'and date(r.site_timestamp) = h.first_order_date' after WHERE Best regards, Alexander Kirpa ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [PERFORM] shared buffers

Chris, Would you say that 3 pages is a good maximum for a Postgres install? We're running 8.0.3 on 64-bit SUSE on a dual Opteron box with 4G and have shared_buffers set at 12. I've moved it up and down (it was 16 when I got here) without any measurable performance difference. The reas

[PERFORM] Postgresql Hardware - Recommendations

Hello, My company has decided to migrate our Oracle database to postgresql8. We will aquire a new server for this, and would very much appreciate your advice. NOTE: The applications accessing the database are developed and maintained externally, and unfortunately, the developers have not yet give

Re: [PERFORM] Query slow after VACUUM ANALYZE

Hi again [..] > >QUERY PLAN > - > Seq Scan on orders (cost=0.00..12184.14 rows=29526 width=33) >Filter: (NOT (hashed subplan)) >SubPlan > -> Seq Scan on orders_items (cost=0.00

Re: [PERFORM] Query slow after VACUUM ANALYZE

[EMAIL PROTECTED] writes: > Any ideas what I can do to make the query running in < 10 seconds? Increase work_mem (or sort_mem in older releases). PG is dropping back from the hash plan because it thinks the hashtable won't fit in work_mem. regards, tom lane -

Re: [PERFORM] Need for speed 3

Ulrich, Luke cc'd me on his reply and you definitely should have a look at Bizgres Clickstream. Even if the whole stack doesn't match you needs, though it sounds like it would. The clickstream focused TELL and BizGres enhancements could make your life a little easier. Basically the stack componen

Re: [PERFORM] Observation about db response time

On Tue, 2005-08-30 at 08:13 -0500, Frank Wiles wrote: > On Tue, 30 Aug 2005 18:35:30 +0530 > "Akshay Mathur" <[EMAIL PROTECTED]> wrote: > > > Hello Friends, > > > > We were having a database in pgsql7.4.2 The database was responding > > very slowly even after full vacuum analyze (select count(*)

Re: [PERFORM] When to do a vacuum for highly active table

> -Original Message- > From: [EMAIL PROTECTED] [mailto:pgsql-performance- > [EMAIL PROTECTED] On Behalf Of Markus Benne > Sent: Wednesday, August 31, 2005 12:14 AM > To: pgsql-performance@postgresql.org > Subject: [PERFORM] When to do a vacuum for highly active table > > We have a highly