Re: [PERFORM] wal sync method

2006-03-01 Thread PFC
Hm, i seem to have mixed fwrite() (which buffers data in userspace) and write() (which apparently doesnt !) Sorry ! PFC <[EMAIL PROTECTED]> writes: Just a stupid question about the various fsync settings. There is fsync=off, but is there fsync=fflush ? fflu

[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 n

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

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 enough

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

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 quali

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 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 a

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 deta

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