Re: [PERFORM] Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc?

2011-11-03 Thread Justin Pitts
On Wed, Nov 2, 2011 at 11:13 AM, Robert Haas robertmh...@gmail.com wrote: […] Perhaps we could let people say something like WITH x AS FENCE (...) when they want the fencing behavior, and otherwise assume they don't (but give it to them anyway if there's a data-modifying operation in there).

Re: [PERFORM] issue related to logging facility of postgres

2011-09-01 Thread Justin Pitts
Syslog does that, I believe. Have a look at the man page for syslog.conf. On Wed, Jul 27, 2011 at 5:11 AM, shailesh singh shaileshj...@gmail.com wrote: Hi, I want to configure Logging of postgres in such a way that messages of different severity should be logged in different log file. eg: all

Re: [PERFORM] table size is bigger than expected

2011-08-04 Thread Justin Pitts
On Thu, Aug 4, 2011 at 2:56 PM, Jian Shi j...@unitrends.com wrote: Hey,   I’m a new user of PostgreSQL. I found one of my tables is taking unexpectedly large space: select pg_size_pretty(pg_relation_size('archive_files'));  pg_size_pretty 1113 MB the field “fname”

Re: [PERFORM] Intel SSDs that may not suck

2011-03-29 Thread Justin Pitts
The potential breakthrough here with the 320 is consumer grade SSD performance and price paired with high reliability. On Mon, Mar 28, 2011 at 7:54 PM, Andy angelf...@yahoo.com wrote: This might be a bit too little too late though. As you mentioned there really isn't any real performance

Re: [PERFORM] Shouldn't we have a way to avoid risky plans?

2011-03-23 Thread Justin Pitts
On Wed, Mar 23, 2011 at 1:12 PM, Josh Berkus j...@agliodbs.com wrote: AFAICT, what's happening in this query is that PostgreSQL's statistics on the device_nodes and several other tables are slightly out of date (as in 5% of the table). What about some manner of query feedback mechanism ( along

Re: [PERFORM] high user cpu, massive SELECTs, no io waiting problem

2011-02-17 Thread Justin Pitts
I think adding UNION ALL SELECT 'postgres version', version(); might be a good thing. On Wed, Feb 16, 2011 at 9:55 AM, Greg Smith g...@2ndquadrant.com wrote: Kevin Grittner wrote: In fact, I wonder whether we shouldn't leave a couple items you've excluded, since they are sometimes germane

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-03 Thread Justin Pitts
With all due respect, I consider myself smarter than the optimizer.  I'm 6'4, 235LBS so telling me that you disagree and that I am more stupid than a computer program,  would not be a smart thing to do. Please, do not misunderestimate me. I don't see computer programs make thinly veiled

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-03 Thread Justin Pitts
Thank you. It appears I owe an apology also, for jumping to that conclusion. It was rash and unfair of me. I am sorry. On Wed, Feb 2, 2011 at 5:03 PM, Mladen Gogala mladen.gog...@vmsinfo.com wrote: Justin Pitts wrote: With all due respect, I consider myself smarter than the optimizer.  I'm

Re: [PERFORM] High load,

2011-01-27 Thread Justin Pitts
Number of logical CPUs: 16 (4x Quadcore Xeon E5520  @ 2.27GHz) RAM: 16GB Concurrent connections (according to our monitoring tool): 7 (min), 74 (avg), 197 (max) Your current issue may be IO wait, but a connection pool isn't far off in your future either. max_connections = 200 work_mem =

Re: [PERFORM] Compared MS SQL 2000 to Postgresql 9.0 on Windows

2010-12-19 Thread Justin Pitts
If you strictly have an OLTP workload, with lots of simultaneous connections issuing queries across small chunks of data, then PostgreSQL would be a good match for SQL server. This matches my observations. In fact, PostgreSQL's MVCC seems to work heavily in my favor in OLTP workloads. On the

Re: [PERFORM] Select * is very slow

2010-11-08 Thread Justin Pitts
On Mon, Nov 8, 2010 at 1:16 AM, shaiju.ck shaiju...@gmail.com wrote: [] I have increased the shared_buffres to 1024MB, but no improvement. I have noticed that the query show shared_buffers always show 8MB.Why is this? Does it mean that changing the shared_buffers in config file have no

Re: [PERFORM] temporary tables, indexes, and query plans

2010-10-29 Thread Justin Pitts
If you alter the default_statistics_target or any of the specific statistics targets ( via ALTER TABLE SET STATISTICS ) , the change will not have an effect until an analyze is performed. This is implied by http://www.postgresql.org/docs/9.0/static/planner-stats.html and

Re: [PERFORM] temporary tables, indexes, and query plans

2010-10-29 Thread Justin Pitts
Jason Pitts: RE: changing default_statistics_target (or via ALTER TABLE SET STATS) not taking effect until ANALYZE is performed. I did already know that, but it's probably good to put into this thread. However, you'll note that this is a temporary table created at the beginning of a

Re: [PERFORM] Advice configuring ServeRAID 8k for performance

2010-08-12 Thread Justin Pitts
As others said, RAID6 is RAID5 + a hot spare. No. RAID6 is NOT RAID5 plus a hot spare. The original phrase was that RAID 6 was like RAID 5 with a hot spare ALREADY BUILT IN. Built-in, or not - it is neither. It is more than that, actually. RAID 6 is like RAID 5 in that it uses parity for

Re: [PERFORM] Advice configuring ServeRAID 8k for performance

2010-08-07 Thread Justin Pitts
Yes, I know that.  I am very familiar with how RAID6 works.  RAID5 with the hot spare already rebuilt / built in is a good enough answer for management where big words like parity might scare some PHBs. In terms of storage cost, it IS like paying for RAID5 + a hot spare, but the protection

Re: [PERFORM] Building multiple indexes concurrently

2010-03-22 Thread Justin Pitts
It seems to me that a separate partition / tablespace would be a much simpler approach. On Mar 17, 2010, at 5:18 PM, Hannu Krosing wrote: On Wed, 2010-03-17 at 16:49 -0400, Greg Smith wrote: Alvaro Herrera wrote: Andres Freund escribió: I find it way much easier to believe such issues

Re: [PERFORM] Building multiple indexes concurrently

2010-03-22 Thread Justin Pitts
Yes. On Mar 18, 2010, at 5:20 PM, Hannu Krosing wrote: On Thu, 2010-03-18 at 16:12 -0400, Justin Pitts wrote: It seems to me that a separate partition / tablespace would be a much simpler approach. Do you mean a separate partition/ tablespace for _each_ index built concurrently

Re: [PERFORM] Testing FusionIO

2010-03-17 Thread Justin Pitts
On Mar 17, 2010, at 10:41 AM, Brad Nicholson wrote: On Wed, 2010-03-17 at 09:52 -0400, Justin Pitts wrote: FusionIO is publicly claiming 24 years @ 5TB/day on the 80GB SLC device, which wear levels across 100GB of actual installed capacity. http://community.fusionio.com/forums/p/34/258

Re: [PERFORM] Testing FusionIO

2010-03-17 Thread Justin Pitts
On Mar 17, 2010, at 9:03 AM, Brad Nicholson wrote: I've been hearing bad things from some folks about the quality of the FusionIO drives from a durability standpoint. Can you be more specific about that? Durability over what time frame? How many devices in the sample set? How did FusionIO

Re: [PERFORM] Testing FusionIO

2010-03-17 Thread Justin Pitts
warranty they have on the devices. FusionIO's claim _seems_ credible. I'd love to see some evidence to the contrary. On Mar 17, 2010, at 9:18 AM, Brad Nicholson wrote: On Wed, 2010-03-17 at 09:11 -0400, Justin Pitts wrote: On Mar 17, 2010, at 9:03 AM, Brad Nicholson wrote: I've been hearing

Re: [PERFORM] cluster index on a table

2009-07-16 Thread Justin Pitts
Is there any interest in adding that (continual/automatic cluster order maintenance) to a future release? On Wed, Jul 15, 2009 at 8:33 PM, Scott Careysc...@richrelevance.com wrote: If you have a lot of insert/update/delete activity on a table fillfactor can help. I don’t believe that postgres

Re: [PERFORM] cluster index on a table

2009-07-16 Thread Justin Pitts
a performance perspective. IOT in Oracle is a huge win in some cases, but a bit more clunky for others than Clustered Indexes in MSSQL. Both are highly useful. On 7/16/09 10:52 AM, Justin Pitts justinpi...@gmail.com wrote: ISTR that is the approach that MSSQL follows. Storing the full tuple

Re: [PERFORM] cluster index on a table

2009-07-16 Thread Justin Pitts
ISTR that is the approach that MSSQL follows. Storing the full tuple in an index and not even having a data only page would also be an interesting approach to this (and perhaps simpler than a separate index file and data file if trying to keep the data in the order of the index). --

Re: [PERFORM] Postgres 8.x on Windows Server in production

2009-04-13 Thread Justin Pitts
You'll almost certainly want to use NTFS. I suspect you'll want to set the NTFS Allocation Unit Size to 8192 or some integer multiple of 8192, since I believe that is the pg page size. XP format dialog will not allow you to set it above 4096, but the command line format utility will. I do