On Wed, Nov 2, 2011 at 11:13 AM, Robert Haas 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).
>
I would love t
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 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 ERROR
> message shou
On Thu, Aug 4, 2011 at 2:56 PM, Jian Shi 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” sto
On Fri, Apr 29, 2011 at 10:24 AM, Mark Steben
wrote:
> Just wondering if anyone has had any experience with this company and these
> cards. We're currently at postgres 8.3.11.
td;dr Ask for a sample and test it out for yourself.
I asked for, and received, a sample 80GB unit from Fusion to test
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 wrote:
> This might be a bit too little too late though. As you mentioned there really
> isn't any real performance improvement for the Int
On Wed, Mar 23, 2011 at 1:12 PM, Josh Berkus 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 the lines
of w
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 wrote:
> Kevin Grittner wrote:
>>
>> In fact, I wonder whether we shouldn't leave a couple items you've
>> excluded, since they are sometimes germane to problems pos
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 wrote:
> Justin Pitts wrote:
>>>
>>> With all
>>> due respect, I consider myself smarter than the op
> 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
> 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
> 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
On Mon, Nov 8, 2010 at 1:16 AM, shaiju.ck 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 impact? Can anybo
> 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 t
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
http://www.postgresql.org/
>>> 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 pari
> 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 prote
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
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
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
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 de
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.fus
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).
--
S
ell from 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" wrote:
ISTR that is the approach that MSSQL follows.
Storing the full tuple in a
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 Carey wrote:
> If you have a lot of insert/update/delete activity on a table fillfactor can
> help.
>
> I don’t believe that postgres will try and mainta
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 remember
25 matches
Mail list logo
