On Mon, 12 May 2008, Francisco Reyes wrote:
We are going to redo one machine to compare RAID 10 vs RAID 50. Mostly to
see if the perfomance is close, the space gain may be usefull.
Good luck with that, you'll need it.
Will it pay to go to a controller with higher memory for existing
Hi,
We want to migrate from postgres 8.1.3 to postgres 8.3.1.
Can anybody list out the installation steps to be followed for migration.
Do we require to take care of something specially.
Thanks in advance
~ Gauri
We want to migrate from postgres 8.1.3 to postgres 8.3.1.
Can anybody list out the installation steps to be followed for migration.
Do we require to take care of something specially.
Perform a pg_dump, do a restore and validate your sql-queries on a test-server.
--
regards
Claus
When lenity
On Mon, May 12, 2008 at 8:04 PM, Francisco Reyes [EMAIL PROTECTED] wrote:
Inheritted a number of servers and I am starting to look into the hardware.
So far what I know from a few of the servers
Redhat servers.
15K rpm disks, 12GB to 32GB of RAM.
Adaptec 2120 SCSI controller (64MB of cache).
On Mon, May 12, 2008 at 11:40 PM, Gauri Kanekar
[EMAIL PROTECTED] wrote:
Hi,
We want to migrate from postgres 8.1.3 to postgres 8.3.1.
Can anybody list out the installation steps to be followed for migration.
Do we require to take care of something specially.
First, I'd recommend updating
Will it pay to go to a controller with higher memory for existing
machines? The one machine I am about to redo has PCI which seems to
somewhat limit our options.
Urgh.
You say that like you don't mind having PCI in a server whose job is to
perform massive query over large data
PFC writes:
You say that like you don't mind having PCI in a server whose job is to
perform massive query over large data sets.
I am in my 4th week at a new job. Trying to figure what I am working with.
From what I see I will likely get as much improvement from new hardware as
from
On Tue, May 13, 2008 at 8:00 AM, Francisco Reyes [EMAIL PROTECTED] wrote:
PFC writes:
You say that like you don't mind having PCI in a server whose job
is to perform massive query over large data sets.
I am in my 4th week at a new job. Trying to figure what I am working with.
Hi,
Along these lines, the usual upgrade path is a pg_dump/pg_restore set.
However, what if your database is large ( 50GB), and you have to
minimize your downtime (say less than an hour or two). Any suggestions
on how to handle that kind of situation? It sure would be nice to have
some kind of
On Tue, May 13, 2008 at 6:00 AM, Knight, Doug [EMAIL PROTECTED] wrote:
Hi,
Along these lines, the usual upgrade path is a pg_dump/pg_restore set.
However, what if your database is large ( 50GB), and you have to
minimize your downtime (say less than an hour or two). Any suggestions
on how to
On May 12, 2008, at 10:04 PM, Francisco Reyes wrote:
Adaptec 2120 SCSI controller (64MB of cache).
The servers have mostly have 12 drives in RAID 10.
We are going to redo one machine to compare RAID 10 vs RAID 50.
Mostly to see if the perfomance is close, the space gain may be
usefull.
On May 12, 2008, at 11:24 PM, Francisco Reyes wrote:
Any PCI controller you have had good experience with?
How any other PCI-X/PCI-e controller that you have had good results?
The LSI controllers are top-notch, and always my first choice. They
have PCI-X and PCI-e versions.
--
Sent via
Hi everybody,
I'm fairly new to PostgreSQL and I have a problem with
a query:
SELECT * FROM LockerEvents LIMIT 1 OFFSET
1099
The table LockerEvents has 11 Mlillions records on it
and this query takes about 60 seconds to complete.
Moreover, even after making for each column in the
table
idc danny wrote:
Hi everybody,
I'm fairly new to PostgreSQL and I have a problem with
a query:
SELECT * FROM LockerEvents LIMIT 1 OFFSET
1099
The table LockerEvents has 11 Mlillions records on it
and this query takes about 60 seconds to complete.
The OFFSET clause is almost always
In response to idc danny [EMAIL PROTECTED]:
Hi everybody,
I'm fairly new to PostgreSQL and I have a problem with
a query:
SELECT * FROM LockerEvents LIMIT 1 OFFSET
1099
This query makes no sense, and I can't blame PostgreSQL for using a
seq scan, since you've given it no reason
idc danny wrote:
Hi everybody,
I'm fairly new to PostgreSQL and I have a problem with
a query:
SELECT * FROM LockerEvents LIMIT 1 OFFSET
1099
The table LockerEvents has 11 Mlillions records on it
and this query takes about 60 seconds to complete.
Moreover, even after making for each
idc danny wrote:
Hi James,
Than you for your response.
What I want to achieve is to give to the application
user 10k rows where the records are one after another
in the table, and the application has a paginating GUI
(First page, Previous page, Next page, Last
page - all links Jump to page
On Tue, May 13, 2008 at 10:57 AM, idc danny [EMAIL PROTECTED] wrote:
Hi everybody,
I'm fairly new to PostgreSQL and I have a problem with
a query:
SELECT * FROM LockerEvents LIMIT 1 OFFSET
1099
The table LockerEvents has 11 Mlillions records on it
and this query takes about 60
PFC wrote:
PCI limits you to 133 MB/s (theoretical), actual speed being
around 100-110 MB/s.
Many servers do have more than one bus. You have to process that data
too so its not going to be as much of a limit as you are suggesting. It
may be possible to stream a compressed data file to
You say that like you don't mind having PCI in a server whose job is
to perform massive query over large data sets.
I am in my 4th week at a new job. Trying to figure what I am working
with.
LOOL, ok, hehe, not exactly the time to have a let's change everything
fit ;)
From what I
Hi all,
This sql is taking too long for the size of my tiny db. Any tips from
this alias? I tried moving the sort to the first left outer join
(between projects and features tables) using a nested subquery, but
postgres tells me only one column could be returned from a subqueyr.
TIA,
fdo
21 matches
Mail list logo
