Re: [PERFORM] count * performance issue

A Dimarts 11 Març 2008 04:11, Scott Marlowe va escriure: On Mon, Mar 10, 2008 at 7:57 PM, Robins Tharakan [EMAIL PROTECTED] wrote: Hi, I have been reading this conversation for a few days now and I just wanted to ask this. From the release notes, one of the new additions in 8.3 is

Re: [PERFORM] Very slow (2 tuples/second) sequential scan afterbulk insert; speed returns to ~500 tuples/second after commit

Simon Riggs wrote: On Mon, 2008-03-10 at 11:01 +, Heikki Linnakangas wrote: According to oprofile, all the time is spent in TransactionIdIsInProgress. I recently submitted a patch to optimise this. Your comments would be welcome on the patch. You mean this one:

[PERFORM] how many index can have????

I have one table with 30 fields, i have more then 60 million records, if i use more no of indexes will it affect the insertion performance? and select performance? Shall i have more then one partial index for same field, -- With Best Regards, Petchimuthulingam S

Re: [PERFORM] count * performance issue

In response to Robins Tharakan [EMAIL PROTECTED]: Hi, I have been reading this conversation for a few days now and I just wanted to ask this. From the release notes, one of the new additions in 8.3 is (Allow col IS NULL to use an index (Teodor)). Sorry, if I am missing something here,

[PERFORM] list user created triggers

how to find trigger names in my database ? using psql 7.4 the following query shows system triggers, i want only to list the triggers created by me select relname, tgname, tgtype, proname, prosrc, tgisconstraint, tgconstrname, tgconstrrelid, tgdeferrable, tginitdeferred, tgnargs, tgattr, tgargs

Re: [PERFORM] how many index can have????

On 11-Mar-08, at 8:28 AM, petchimuthu lingam wrote: I have one table with 30 fields, i have more then 60 million records, if i use more no of indexes will it affect the insertion performance? and select performance? Yes, and yes, but without more information about what you are trying to

Re: [PERFORM] count * performance issue

On Tue, 11 Mar 2008, Bill Moran wrote: In response to Robins Tharakan [EMAIL PROTECTED]: Sorry, if I am missing something here, but shouldn't something like this allow us to get a (fast) accurate count ? SELECT COUNT(*) from table WHERE indexed_field IS NULL + SELECT COUNT(*) from table WHERE

Re: [PERFORM] count * performance issue

Hi, Matthew wrote: On Tue, 11 Mar 2008, Bill Moran wrote: In response to Robins Tharakan [EMAIL PROTECTED]: Sorry, if I am missing something here, but shouldn't something like this allow us to get a (fast) accurate count ? SELECT COUNT(*) from table WHERE indexed_field IS NULL + SELECT

Re: [PERFORM] count * performance issue

Matthew wrote: No, actually I was referring to a race condition. So, you find the count of rows with IS NULL, then someone changes a row, then you find the count of rows with IS NOT NULL. Add the two together, and there may be rows that were counted twice, or not at all. Not a problem if you

Re: [PERFORM] count * performance issue

On Tue, Mar 11, 2008 at 02:19:09PM +, Matthew wrote: of rows with IS NULL, then someone changes a row, then you find the count of rows with IS NOT NULL. Add the two together, and there may be rows that were counted twice, or not at all. Only if you count in READ COMMITTED. A -- Sent

Re: [PERFORM] Joins and DELETE FROM

Thank you for your post. I finally spent some quality time with the query planner section in the docs' server config chapter. Very instructive, even considering that most of it went over my head! On Sat, Mar 8, 2008 at 4:08 PM, Tom Lane [EMAIL PROTECTED] wrote: ...have you got

Re: [PERFORM] how many index can have????

petchimuthu lingam wrote: I have one table with 30 fields, i have more then 60 million records, if i use more no of indexes will it affect the insertion performance? and select performance? Maintaining an index has a cost. That means that every time a record covered by an index is added,

Re: [PERFORM] list user created triggers

thanks... after this query also it is showing default triggers ( am very much worried that how the system triggers are created using my username ok i posted this in the group you specified.. On Tue, Mar 11, 2008 at 8:03 PM, Sergey Benner [EMAIL PROTECTED] wrote: Again :) Try this query.

Re: [PERFORM] list user created triggers

select usename,relname, tgname, tgtype, proname, prosrc, tgisconstraint, tgconstrname, tgconstrrelid, tgdeferrable, tginitdeferred, tgnargs, tgattr, tgargs from (pg_trigger join pg_class c on tgrelid=c.oid ) join pg_proc on (tgfoid=pg_proc.oid) join pg_user pu on c.relowner=pu.usesysid

Re: [PERFORM] migration of 7.4 to 8.1

sathiya psql wrote: Is there any article describing the migration database from postgresql 7.4to 8.1 This might be a silly question, but ... why 8.1 ? If you're doing a major upgrade, why not go straight to 8.3? It's been out long enough that there aren't any obvious nasty bugs, and there