[PERFORM] Bad plan on a view

2006-03-01 Thread PFC
I have a table with a few small numeric fields and several text fields, on pg. 8.1.2. The numeric fields are used for searching (category_id, price, etc). The text fields are just a description of the item, comments, email address, telephone, etc. So, in order to speed up requests which

Re: [PERFORM] Bad plan on a view

2006-03-01 Thread Tom Lane
PFC [EMAIL PROTECTED] writes: So, in order to speed up requests which need a full table scan, I wanted to put the text fields in another table, and use a view to make it look like nothing happened. Also, the small table used for searching is a lot more likely to fit in RAM than the big

Re: [PERFORM] Bad plan on a view

2006-03-01 Thread PFC
Aren't you going to a lot of work to reinvent something that TOAST already does for you? (At least, in the cases where the text fields are wide enough that it really matters.) I know. But I have several text fields in the 20 to 200 characters, which is too small for toast, but large

Re: [PERFORM] Bad plan on a view

2006-03-01 Thread Greg Stark
Tom Lane [EMAIL PROTECTED] writes: PFC [EMAIL PROTECTED] writes: So, in order to speed up requests which need a full table scan, I wanted to put the text fields in another table, and use a view to make it look like nothing happened. Also, the small table used for searching is a lot

Re: [PERFORM] Bad plan on a view

2006-03-01 Thread PFC
While TOAST has a similar goal I don't think it has enough AI to completely replace this manual process. It suffers in a number of use cases: 1) When you have a large number of moderate sized text fields instead of asingle very large text field. This is probably the case here.

Re: [PERFORM] [HACKERS] temporary indexes

2006-03-01 Thread Kevin Grittner
On Tue, Feb 28, 2006 at 3:02 pm, in message [EMAIL PROTECTED], Jim C. Nasby [EMAIL PROTECTED] wrote: Maybe it's just the way my twisted mind thinks, but I generally prefer using a JOIN when possible... Definitely. But sometimes you don't want one row from a table for each qualifying row

Re: [PERFORM] Looking for a tool to * pg tables as ERDs

2006-03-01 Thread Robert Treat
On Thu, 2006-02-23 at 11:38, Ron Peacetree wrote: Where * == {print | save to PDF | save to mumble format | display on screen} Anyone know of one? case studio can reverse engineer erd's from existing schema, and you can print out the schema, create html or rdf reports, or export the erd

Re: [PERFORM] triggers, performance Was: Re: [GENERAL] rotate records

2006-03-01 Thread Jim C. Nasby
And what do those functions do? And do their options trigger other triggers? How about an EXPLAIN ANALYZE from a problem query, too. On Tue, Feb 28, 2006 at 11:24:34AM +0530, Jeevanandam, Kathirvel (IE10) wrote: I am using triggers for all the events (insert,delete,update) please find the

Re: [PERFORM] Bad plan on a view

2006-03-01 Thread Jim C. Nasby
On Wed, Mar 01, 2006 at 04:43:53PM +0100, PFC wrote: Aren't you going to a lot of work to reinvent something that TOAST already does for you? (At least, in the cases where the text fields are wide enough that it really matters.) I know. But I have several text fields in the 20 to