On Thursday, January 3, 2013, Alex Vinnik wrote:
> Hi everybody,
>
> I have implemented my first app using PG DB and thought for a minute(may
> be two) that I know something about PG but below
> problem totally destroyed my confidence :). Please help me to restore it.
>
> Here is simple join query
On Tuesday, January 08, 2013 03:48:38 PM Shaun Thomas wrote:
> On 01/08/2013 02:05 PM, AJ Weber wrote:
> > Is there an "easy" way to tell what scheduler my OS is using?
>
> Unfortunately not. I looked again, and it seems that CFS was merged into
> 2.6.23. Anything before that is probably safe, but
On 01/08/2013 02:05 PM, AJ Weber wrote:
Is there an "easy" way to tell what scheduler my OS is using?
Unfortunately not. I looked again, and it seems that CFS was merged into
2.6.23. Anything before that is probably safe, but the vendor may have
backported it. If you don't see the settings I
When I checked these, both of these settings exist on my CentOS 6.x host
(2.6.32-279.5.1.el6.x86_64).
However, the autogroup_enabled was already set to 0. (The
migration_cost was set to the 0.5ms, default noted in the OP.) So I
don't know if this is strictly limited to kernel 3.0.
Is there
On 01/08/2013 01:04 PM, Scott Marlowe wrote:
Assembly language on the brain. of course I meant NOOP.
Ok, in that case, these are completely separate things. For IO
scheduling, there's the Completely Fair Queue (CFQ), NOOP, Deadline, and
so on.
For process scheduling, at least recently, th
On Tue, Jan 8, 2013 at 11:36 AM, Shaun Thomas wrote:
> On 01/08/2013 12:31 PM, Scott Marlowe wrote:
>
>> What's the comparison of these settings versus say going to the NOP
>> scheduler?
>
>
> Assuming you actually meant NOP and not the NOOP I/O scheduler, I don't
> know. These CPU scheduler tweak
On 01/08/2013 12:31 PM, Scott Marlowe wrote:
What's the comparison of these settings versus say going to the NOP
scheduler?
Assuming you actually meant NOP and not the NOOP I/O scheduler, I don't
know. These CPU scheduler tweaks are all I could dig up, and googling
for NOP by itself or combi
On Tue, Jan 8, 2013 at 11:28 AM, Shaun Thomas wrote:
> On 01/08/2013 12:25 PM, Midge Brown wrote:
>
>> The kernel on our Linux system doesn't appear to have these two
>> settings according to the list provided by sysctl -a. Please pardon
>> my ignorance, but should I add them?
>
>
> Sorry if I was
On 01/08/2013 12:25 PM, Midge Brown wrote:
The kernel on our Linux system doesn't appear to have these two
settings according to the list provided by sysctl -a. Please pardon
my ignorance, but should I add them?
Sorry if I wasn't more clear. These only apply to Linux systems with the
Complete
The kernel on our Linux system doesn't appear to have these two settings
according to the list provided by sysctl -a. Please pardon my ignorance, but
should I add them?
We have Postgresql 9.0 on Linux 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT
2009 x86_64 x86_64 x86_64 GNU/Linux
Thanks,
Mid
It does if you use it without an argument, to display all the tables
in the search path:
jjanes=# \d+
List of relations
Schema | Name | Type | Owner | Size | Description
+--+---++-+-
public |
Jeff Janes writes:
> On Tue, Jan 8, 2013 at 8:45 AM, AJ Weber wrote:
>>
>> \d+ doesn't appear to display any size information.
> It does if you use it without an argument, to display all the tables
> in the search path:
> jjanes=# \d+
> List of relations
> Schema |
On Tue, Jan 8, 2013 at 8:45 AM, AJ Weber wrote:
>
>>
>> It probably does, but from psql command line, you can do \d+ and \di+
>
> \d+ doesn't appear to display any size information.
It does if you use it without an argument, to display all the tables
in the search path:
jjanes=# \d+
It probably does, but from psql command line, you can do \d+ and \di+
\d+ doesn't appear to display any size information.
If you have little control over your storage and are already IO bound,
and the tables are growing rapidly, you may need to rethink that
"deletes are rare" bit. So the
Hi Ken,
Thanks for reply.
After researching, I get more understanding with the importance of the ZIL
http://constantin.glez.de/blog/2010/07/solaris-zfs-synchronous-writes-and-zil-explained
So the performance issue is the ZIL...
BTW, using a standard UFS+software update is still slower than Linux
On Sunday, January 6, 2013, AJ Weber wrote:
> All fair questions...
>
> Thank you for your detailed response!
>
>
> On 1/4/2013 11:03 PM, Jeff Janes wrote:
>
> On Friday, January 4, 2013, AJ Weber wrote:
>
>> Hi all,
>>
>> I have a table that has about 73mm rows in it and growing.
>
>
> How big
On 01/08/2013 09:29 AM, Andrea Suisani wrote:
On 01/02/2013 10:46 PM, Shaun Thomas wrote:
Hey everyone!
After much testing and hair-pulling, we've confirmed two kernel settings that
> should always be modified in production Linux systems. Especially new ones
with
the completely fair schedul
On 01/02/2013 10:46 PM, Shaun Thomas wrote:
Hey everyone!
After much testing and hair-pulling, we've confirmed two kernel settings that
> should always be modified in production Linux systems. Especially new ones
with
the completely fair scheduler (CFS) as opposed to the O(1) scheduler.
[cu
18 matches
Mail list logo
