[PERFORM] Hardware advice for scalable warehouse db

2011-07-14 Thread chris
Hi list, My employer will be donated a NetApp FAS 3040 SAN [1] and we want to run our warehouse DB on it. The pg9.0 DB currently comprises ~1.5TB of tables, 200GB of indexes, and grows ~5%/month. The DB is not update critical, but undergoes larger read and insert operations frequently. My employe

Re: [PERFORM] UPDATEDs slowing SELECTs in a fully cached database

2011-07-14 Thread Jeff Janes
On Wed, Jul 13, 2011 at 3:41 PM, lars wrote: > On 07/13/2011 11:42 AM, Kevin Grittner wrote: >> >> So transactions without an XID *are* sensitive to >> synchronous_commit.  That's likely a useful clue. >> >> How much did it help the run time of the SELECT which followed the >> UPDATE? > > It has s

Re: [PERFORM] UPDATEDs slowing SELECTs in a fully cached database

2011-07-14 Thread Jeff Janes
On Wed, Jul 13, 2011 at 11:10 AM, lars wrote: ... > => update test set created_by = '001' where tenant = > '001'; > UPDATE 3712 ... > > There seems to be definitely something funky going on. Since created_by is > indexed it shouldn't do any HOT logic. Once the update has

Re: [PERFORM] UPDATEDs slowing SELECTs in a fully cached database

2011-07-14 Thread Kevin Grittner
Tom Lane wrote: > It seems like we ought to distinguish heap cleanup activities from > user-visible semantics (IOW, users shouldn't care if a HOT cleanup > has to be done over after restart, so if the transaction only > wrote such records there's no need to flush). This'd require more > process

Re: [PERFORM] UPDATEDs slowing SELECTs in a fully cached database

2011-07-14 Thread Tom Lane
"Kevin Grittner" writes: > Tom Lane wrote: >> It seems like we ought to distinguish heap cleanup activities from >> user-visible semantics (IOW, users shouldn't care if a HOT cleanup >> has to be done over after restart, so if the transaction only >> wrote such records there's no need to flush).

Re: [PERFORM] UPDATEDs slowing SELECTs in a fully cached database

2011-07-14 Thread Robert Klemme
On Thu, Jul 14, 2011 at 4:05 PM, Kevin Grittner wrote: > Tom Lane wrote: > >> It seems like we ought to distinguish heap cleanup activities from >> user-visible semantics (IOW, users shouldn't care if a HOT cleanup >> has to be done over after restart, so if the transaction only >> wrote such rec

Re: [PERFORM] Trigger or Function

2011-07-14 Thread Robert Klemme
On Tue, Jul 12, 2011 at 9:41 AM, alan wrote: > Hello, > I'm a postgres newbie and am wondering what's the best way to do this. > > I am gathering some data and will be inserting to a table once daily. > The table is quite simple but I want the updates to be as efficient as > possible since > this

Re: [PERFORM] Planner choosing NestedLoop, although it is slower...

2011-07-14 Thread Clem Dickey
On 07/12/2011 11:11 AM, Mario Splivalo wrote: Hi, all. I have a query, looking like this: SELECT pub_date FROM tubesite_object INNER JOIN tubesite_image ON tubesite_image.object_ptr_id = tubesite_object.id WHERE tubesite_object.site_id = 8 AND tubesite_object.pub_date < E'2011-07-12 13:25:00' OR

[PERFORM] Trigger or Function

2011-07-14 Thread alan
Hello, I'm a postgres newbie and am wondering what's the best way to do this. I am gathering some data and will be inserting to a table once daily. The table is quite simple but I want the updates to be as efficient as possible since this db is part of a big data project. Say I have a table with