On Wed, 2007-09-12 at 15:14 +0200, Nis Jørgensen wrote:
> El-Lotso skrev:
>
> > I'm on the verge of giving up... the schema seems simple and yet there's
> > so much issues with it. Perhaps it's the layout of the data, I don't
> > know. But based on the ordering/normalisation of the data and the on
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Lane wrote:
> "Steven Flatt" <[EMAIL PROTECTED]> writes:
> > So, can we simply trust what's in pg_class.relpages
"Harsh Azad" <[EMAIL PROTECTED]> writes:
> Where are the database index files located in the $PGDATA directory?
Read
http://www.postgresql.org/docs/8.2/static/storage.html
> I was
> thinking on soft linking them to another physical hard disk array.
Manual symlink management, while not impossible
On Fri, 2007-09-14 at 08:33 +0530, Harsh Azad wrote:
> ah.. thanks. Didn't realize table spaces can be mentioned while
> creating a index. BTW, are soft links ok to use for pg_clog /
> pg_xlog . I moved the existing directories to /mnt/logs/pglogs and
> made soft links for both directories in $PGDA
ah.. thanks. Didn't realize table spaces can be mentioned while creating a
index. BTW, are soft links ok to use for pg_clog / pg_xlog . I moved the
existing directories to /mnt/logs/pglogs and made soft links for both
directories in $PGDATA
Thanks
On 9/14/07, Ow Mun Heng <[EMAIL PROTECTED]> wrote
On Fri, 2007-09-14 at 08:20 +0530, Harsh Azad wrote:
> Hi,
>
> Where are the database index files located in the $PGDATA directory? I
> was thinking on soft linking them to another physical hard disk array.
you have to search through pg_class for the "number"
Alternatively, you can try using tab
Hi,
Where are the database index files located in the $PGDATA directory? I was
thinking on soft linking them to another physical hard disk array.
Thanks,
Azad
On Thu, 13 Sep 2007, Brad Nicholson wrote:
A sysadmin looked at cache usage on the disk array. The read cache is
being used heavily, and the write cache is not.
Given that information, you can take the below (which I was just about to
send before the above update came in) as something to thi
On Tue, Sep 11, 2007 at 06:07:44PM -0500, Decibel! wrote:
On Tue, Sep 11, 2007 at 05:09:00PM -0400, Michael Stone wrote:
You can get DAS arrays with multiple controllers, PSUs, etc. DAS !=
single disk.
It's still in the same chassis, though,
I think you're confusing DAS and internal storage
On Thu, 2007-09-13 at 12:12 -0400, Greg Smith wrote:
> Since you're probably not monitoring I/O waits and similar statistics on
> how the disk array's cache is being used, whether this is happening or not
> to you won't be obvious from what the operating system is reporting.
A sysadmin looked
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> "Luke Lonergan" <[EMAIL PROTECTED]> writes:
>
>> Right now the pattern for index scan goes like this:
>>
>> - Find qualifying TID in index
>> - Seek to TID location in relfile
>> - Acquire tuple from relfile, return
>>...
>> If we implement AIO
Brad Nicholson wrote:
> On Thu, 2007-09-13 at 12:19 -0400, Brad Nicholson wrote:
> > On Thu, 2007-09-13 at 12:12 -0400, Greg Smith wrote:
> > > On Thu, 13 Sep 2007, Brad Nicholson wrote:
> >
> > > I'd be curious to see how you've got your background writer configured to
> > > see if it matches si
On Thu, 2007-09-13 at 12:19 -0400, Brad Nicholson wrote:
> On Thu, 2007-09-13 at 12:12 -0400, Greg Smith wrote:
> > On Thu, 13 Sep 2007, Brad Nicholson wrote:
>
> > I'd be curious to see how you've got your background writer configured to
> > see if it matches situations like this I've seen in th
On 9/13/07, Erik Jones <[EMAIL PROTECTED]> wrote:
> On Sep 13, 2007, at 12:58 AM, Greg Smith wrote:
>
> > On Wed, 12 Sep 2007, Scott Marlowe wrote:
> >
> >> I'm getting more and more motivated to rewrite the vacuum docs. I
> >> think a rewrite from the ground up might be best... I keep seeing
> >
On Thu, 2007-09-13 at 12:12 -0400, Greg Smith wrote:
> On Thu, 13 Sep 2007, Brad Nicholson wrote:
> I'd be curious to see how you've got your background writer configured to
> see if it matches situations like this I've seen in the past. The
> parameters controlling the all scan are the ones yo
On Thu, 13 Sep 2007, Brad Nicholson wrote:
One big difference though is that the old array had 16 GB of cache, the
new one has 4 GB.
We have enough IO to spare that we have the bgwriter cranked up pretty
high, dirty buffers are getting quickly.
If your system is very active, running the bgw
On Sep 13, 2007, at 12:58 AM, Greg Smith wrote:
On Wed, 12 Sep 2007, Scott Marlowe wrote:
I'm getting more and more motivated to rewrite the vacuum docs. I
think a rewrite from the ground up might be best... I keep seeing
people doing vacuum full on this list and I'm thinking it's as
mu
On Thu, 2007-09-13 at 11:10 -0400, Tom Lane wrote:
> Brad Nicholson <[EMAIL PROTECTED]> writes:
> > On Thu, 2007-09-13 at 10:15 -0400, Brad Nicholson wrote:
> >> I'm having a problem with long running commits appearing in my database
> >> logs. It may be hardware related, as the problem appeared w
How many backends do you have at any given time? Have you tried using
something like pgBouncer to lower backend usage? How about your IO
situation? Have you run something like sysstat to see what iowait is
at?
On 9/11/07, Ruben Rubio <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE---
Brad Nicholson <[EMAIL PROTECTED]> writes:
> On Thu, 2007-09-13 at 10:15 -0400, Brad Nicholson wrote:
>> I'm having a problem with long running commits appearing in my database
>> logs. It may be hardware related, as the problem appeared when we moved
>> the database to a new server connected to a
[EMAIL PROTECTED] (Patrice Castet) writes:
> I wonder if clustering a table improves perfs somehow ?
> Any example/ideas about that ?
> ref : http://www.postgresql.org/docs/8.2/interactive/sql-cluster.html
Sometimes.
1. It compacts the table, which may be of value, particularly if the
table is n
On Thu, 2007-09-13 at 10:15 -0400, Brad Nicholson wrote:
> I'm having a problem with long running commits appearing in my database
> logs. It may be hardware related, as the problem appeared when we moved
> the database to a new server connected to a different disk array. The
> disk array is a lo
On 9/13/07, Greg Smith <[EMAIL PROTECTED]> wrote:
> On Wed, 12 Sep 2007, Scott Marlowe wrote:
>
> > I'm getting more and more motivated to rewrite the vacuum docs. I think
> > a rewrite from the ground up might be best... I keep seeing people
> > doing vacuum full on this list and I'm thinking it
I'm having a problem with long running commits appearing in my database
logs. It may be hardware related, as the problem appeared when we moved
the database to a new server connected to a different disk array. The
disk array is a lower class array, but still more than powerful enough
to handle th
On 9/13/07, Patrice Castet <[EMAIL PROTECTED]> wrote:
> I wonder if clustering a table improves perfs somehow ?
As I understand it, clustering will help cases where you are fetching
data in the same sequence as the clustering order, because adjacent
rows will be located in adjacent pages on disk;
hi!
I wonder if clustering a table improves perfs somehow ?
Any example/ideas about that ?
ref : http://www.postgresql.org/docs/8.2/interactive/sql-cluster.html
thx,
P.
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Hello,
My question is about index usage when bitwise operations are invoked.
Situation Context:
--
Lets suppose we have 2 tables TBL1 and TBL2 as the following:
TBL1 {
. ;
integer categoryGroup; // categoryGroup is declared as an index on TABL1
. ;
}
27 matches
Mail list logo
