Scott Carey wrote:
I'm also not sure how up to date RedHat's xfs version is -- there have been
enhancements to xfs in the kernel mainline regularly for a long time.
They seem to following SGI's XFS repo quite carefully and cherry-picking
bug fixes out of there, not sure of how that relates
On Mar 9, 2010, at 4:39 PM, Scott Carey wrote:
>
> On Mar 8, 2010, at 11:00 PM, Greg Smith wrote:
>
> * At least with CentOS 5.3 and thier xfs version (non-Redhat, CentOS extras)
> sparse random writes could almost hang a file system. They were VERY slow.
> I have not tested since.
>
Ju
On Mar 8, 2010, at 11:00 PM, Greg Smith wrote:
> Scott Carey wrote:
>> For high sequential throughput, nothing is as optimized as XFS on Linux yet.
>> It has weaknesses elsewhere however.
>>
>
> I'm curious what you feel those weaknesses are. The recent addition of
> XFS back into a more ma
John KEA wrote:
> I am stuck ed now with a problem of large objects deleting,
> please, give me a few advices what do I have to do to improve the
> deleting time?
You've come to the right place, but we need more information to be
able to help. Please review this page and repost with the su
Dear PostgreSQL Creators, I am frequently using PostgreSQL server to manage the
data, but I am stuck ed now with a problem of large objects deleting, namely it
works too slow. E.g., deleting of 900 large objects of 1 Mb size takes around
2.31 minutes. This dataset is not largest one which I am w
On Tue, Mar 9, 2010 at 8:27 AM, Vidhya Bondre wrote:
>>
>> are you using the same postgresql.conf? have you created more
>> partitions? using advisory locks?
>
> Yes we are using same conf files. In a week we create around 5 partitions.
> We are not using advisory locks
>>
>> In any event, incre
On Tue, 9 Mar 2010, Pierre C wrote:
On Tue, 09 Mar 2010 08:00:50 +0100, Greg Smith wrote:
Scott Carey wrote:
For high sequential throughput, nothing is as optimized as XFS on Linux
yet. It has weaknesses elsewhere however.
When files are extended one page at a time (as postgres does) fr
Pierre C escribió:
On Tue, 09 Mar 2010 08:00:50 +0100, Greg Smith
wrote:
Scott Carey wrote:
For high sequential throughput, nothing is as optimized as XFS on
Linux yet. It has weaknesses elsewhere however.
When files are extended one page at a time (as postgres does)
fragmentation can
Cool trick I didn't realise you could do this at the SQL level without
a custom max() written in C.
What I ended up doing for my app is just going with straight SQL that
generates the "key" tuples with a SELECT DISTINCT, and then has a dependent
subquery that does a very small index scan to
Do keep the postgres xlog on a seperate ext2 partition for best
performance. Other than that, xfs is definitely a good performer.
Mike Stone
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgs
On Tue, Mar 9, 2010 at 6:04 PM, Merlin Moncure wrote:
> On Tue, Mar 9, 2010 at 4:38 AM, Vidhya Bondre
> wrote:
> > Hi All,
> >
> > We have installed postgres 8.4.2 on production.
> >
> > We have a parition table structure for one of the table.
> >
> > when i am drop the master table we get the
"Pierre C" wrote:
> Greg Smith wrote:
>> I'm curious what you feel those weaknesses are.
>
> Handling lots of small files, especially deleting them, is really
> slow on XFS.
> Databases don't care about that.
I know of at least one exception to that -- when we upgraded and got
a newer versio
On Tue, Mar 9, 2010 at 4:38 AM, Vidhya Bondre wrote:
> Hi All,
>
> We have installed postgres 8.4.2 on production.
>
> We have a parition table structure for one of the table.
>
> when i am drop the master table we get the following error.
>
> drop table table_name cascade;
> WARNING: out of shar
On Tue, 09 Mar 2010 08:00:50 +0100, Greg Smith
wrote:
Scott Carey wrote:
For high sequential throughput, nothing is as optimized as XFS on Linux
yet. It has weaknesses elsewhere however.
When files are extended one page at a time (as postgres does)
fragmentation can be pretty high on
On Wed, Feb 24, 2010 at 4:31 PM, Dave Crooke wrote:
> This is a generic SQL issue and not PG specific, but I'd like to get
> an opinion from this list.
>
> Consider the following data:
>
> # \d bar
> Table "public.bar"
> Column | Type | Modifiers
> +
Hi All,
We have installed postgres 8.4.2 on production.
We have a parition table structure for one of the table.
when i am drop the master table we get the following error.
drop table table_name cascade;
WARNING: out of shared memory
ERROR: out of shared memory
HINT: You might need to increa
16 matches
Mail list logo
