Re: [PERFORM] Reading recommendations

://www.powerpostgresql.com/Docs/ BTW. If you are a SQL/python programmer in (or near) Lanarkshire, Scotland, we have a vacancy. ;-) Allow telecommute from across the pond and I might be interested :-) -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast

Re: [PERFORM] Million of rows

the database regularly? Have you investigated whether you need to increase the statistics on any columns? Have you tuned postgresql.conf? What version of PostgreSQL are you using? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP

Re: [PERFORM] cpu_tuple_cost

://archives.postgresql.org/pgsql-hackers/2000-02/msg00215.php -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] Help to find out problem with joined tables

else can provide a better explanation. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [PERFORM] Performance problem on delete from for 10k rows. May takes 20 minutes through JDBC interface

been done under different conditions, so it might not mean much. No offense intended, but I remember doesn't carry as much weight as a documented example. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 2: you can get off

Re: [PERFORM] What is the postgres sql command for last_user_id ???

the value of a SERIAL insert? and the question immediately following it in the FAQ: http://www.postgresql.org/files/documentation/faqs/FAQ.html#4.11.2 -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 7: don't forget to increase

Re: [PERFORM] Autocommit

(or END) or ROLLBACK. That is, unless your client intercepts these statements and does whatever it wants -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http

Re: [PERFORM] Autocommit

transactions. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] Are JOINs allowed with DELETE FROM

then automatically delete all associated records in detail. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED

Re: [PERFORM] Accessing insert values in triggers

/plpython-trigger.html -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] Upgrading from from 7.4.2 to 8.0

/static/migration.html (Install or upgrade questions should probably go to pgsql-admin or pgsql-general instead of pgsql-performance.) -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 2: you can get off all lists at once

Re: [PERFORM] TEXT field and Postgresql Perfomance

TABLE SET STORAGE might be appropriate here, but I'll defer that to somebody who understands such things better than me. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] Bad Index Choices with user defined data type

the query and the EXPLAIN ANALYZE output for both cases: one query with enable_seqscan on and one with it off. It might also be useful to see the column's statistics from pg_stats, and perhaps the SQL statements that create the table, the type, the type's operators, etc. -- Michael Fuhr http

Re: [PERFORM] [GENERAL] Query is not using index when it should

. The generating program uses WHERE 1=1 to simplify the addition of other conditions: instead of checking if it needs to add a WHERE and putting ANDs in the right places, it simply appends subsequent conditions with AND condition. -- Michael Fuhr http://www.fuhr.org/~mfuhr

Re: [PERFORM] Tsearch2 really slower than ilike ?

of words then I'd expect tsearch2 to be faster than ILIKE by an order of magnitude or more. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister

Re: [PERFORM] Checking = with timestamp field is slow

foo_date_today_idx ON foo (DATE(today)); After creating the new index, use WHERE DATE(today) = '2004-11-05' in your queries. EXPLAIN ANALYZE should show that the index is being used. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast

Re: [PERFORM] Checking = with timestamp field is slow

-- Index Scan using foo_date_idx on foo (cost=0.00..167.83 rows=50 width=16) (actual time=0.051..0.061 rows=1 loops=1) Index Cond: (date(today) = '2004-11-05'::date) -- Michael Fuhr http://www.fuhr.org/~mfuhr

Re: [PERFORM] Checking = with timestamp field is slow

in queries like this: WHERE today IN ('2004-09-01', '2004-10-01', '2004-11-01'); -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command

[PERFORM] Slow joins against set-returning functions

=10) Index Cond: (stuff.id = outer.id) Total runtime: 2.374 ms (5 rows) Is the planner doing something wrong here? Thanks. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe

<    1   2