Hi all,
Does anyone have any experience with putting PostgreSQL data on a NAS
device?
I am asking this because a NAS device is much cheaper to set up than a
couple of SCSI disks. I would like to use a relatively cheap NAS device
which uses four IDE drives (7.200 rpm), like the Dell PowerVault 725
On Mon, 20 Oct 2003 09:12:35 +0200
"Alexander Priem" <[EMAIL PROTECTED]> wrote:
> I am asking this because a NAS device is much cheaper to set up than a
> couple of SCSI disks. I would like to use a relatively cheap NAS
> device which uses four IDE drives (7.200 rpm), like the Dell
> PowerVault 72
Thanks for your reply, Jeff.
If we are going to use a NAS device for storage, then it will be attached
through a gigabit ethernet connection. Fiber will not be an option, since
that would negate the savings we can make by using an IDE NAS device instead
of SCSI-RAID, fiber's pretty expensive, righ
Alexander Priem wrote:
About clustering: I know this can't be done by hooking multiple postmasters
to one and the same NAS. This would result in data corruption, i've read...
Only if they are reading same data directory. You can run 4 different data
installations of postgresql, each one in its own
Even better than the four-disk NAS I mentioned earlier is the following:
Promise UltraTrak RM8000. This is a so-called SCSI-to-IDE RAID system.
Basically it's a RAID setup of eight IDE disks, using a hardware RAID
engine, that's connected to (in this case) the PostgreSQL server via a SCSI
Ultra160
Alexander Priem kirjutas E, 20.10.2003 kell 15:29:
> Thanks for your reply, Jeff.
>
> If we are going to use a NAS device for storage, then it will be attached
> through a gigabit ethernet connection. Fiber will not be an option, since
> that would negate the savings we can make by using an IDE NA
Alexander Priem kirjutas E, 20.10.2003 kell 16:04:
> Even better than the four-disk NAS I mentioned earlier is the following:
>
> Promise UltraTrak RM8000. This is a so-called SCSI-to-IDE RAID system.
While you are at it, you could also check out http://www.3ware.com/
I guess one of these with 1
Hello Alexander,
On Mon, 2003-10-20 at 06:04, Alexander Priem wrote:
> Even better than the four-disk NAS I mentioned earlier is the following:
>
> Promise UltraTrak RM8000. This is a so-called SCSI-to-IDE RAID system.
> Basically it's a RAID setup of eight IDE disks, using a hardware RAID
> engi
Hi Josh, Tom,
OK. As I understand it, vacuum does not release the space
used by the index file.
However, it should be able to reuse the space for indexing.
I have observed that during initial updates of the table,
the index file did not grow and was steady but it did not last long
and keeps growin
It has been suggested to me that I resubmit this question to this list,
rather than the GENERAL list it was originaly sent to.
I asked earlier about ways of doing an UPDATE involving a left outer
join and got some very useful feedback.
This has thrown up a (to me) strange anomaly about t
Harry,
>It has been suggested to me that I resubmit this question to this list,
> rather than the GENERAL list it was originaly sent to.
>
>I asked earlier about ways of doing an UPDATE involving a left outer
> join and got some very useful feedback.
The query you posted will always be so
On Mon, 20 Oct 2003, Alexander Priem wrote:
> Hi all,
>
> Does anyone have any experience with putting PostgreSQL data on a NAS
> device?
>
> I am asking this because a NAS device is much cheaper to set up than a
> couple of SCSI disks. I would like to use a relatively cheap NAS device
> which u
Hi Tom, Josh,
We tried one more thing: with the table not being updated
at all and we did vacuum. Each time a vacuum is done,
the index file becomes bigger.
This is probably what is contributing to the index file
growing as well.
Thanks.
Gan
At 11:04 am -0500 2003/10/20, Seum-Lim Gan wrote:
Hi J
Seum-Lim Gan <[EMAIL PROTECTED]> writes:
> We tried one more thing: with the table not being updated
> at all and we did vacuum. Each time a vacuum is done,
> the index file becomes bigger.
It is not possible for plain vacuum to make the index bigger.
VACUUM FULL possibly could make the index big
Seum-Lim Gan <[EMAIL PROTECTED]> writes:
> [ successive outputs from VACUUM ANALYZE ]
FWIW, I don't think your problem is really index bloat at all, it's
more like too-many-dead-rows bloat. Note that the number of "dead row
versions" is climbing steadily from run to run:
> DETAIL: 101802 dead r
Folks,
I'm working on the demo session for our upcoming presentation at PHPCon.
As a side issue, we ended up comparing 3 versions of the same search screen:
1) All in PHP with views;
2) Using a function to build a query and count results but executing that
query directly and sorting, paging i
Rhaoni Chiu Pereira kirjutas E, 20.10.2003 kell 17:13:
> Hi List,
>
>I got a P4 1.7Ghz , 512MB RAM , HD 7200 RPM, on RED HAT 9 running PostgreSQL
> 7.3.2-3 Database.
>I have a Delphi aplication that updates the Oracle database using .dbf
> file's information ( converting the data from t
Hi List,
I got a P4 1.7Ghz , 512MB RAM , HD 7200 RPM, on RED HAT 9 running PostgreSQL
7.3.2-3 Database.
I have a Delphi aplication that updates the Oracle database using .dbf
file's information ( converting the data from the old clipper aplication ) and
it takes about 3min and 45 seconds
On Mon, 20 Oct 2003 12:13:26 -0200
Rhaoni Chiu Pereira <[EMAIL PROTECTED]> wrote:
> Hi List,
>
>I got a P4 1.7Ghz , 512MB RAM , HD 7200 RPM, on RED HAT 9 running
>PostgreSQL
> 7.3.2-3 Database.
[clip]
Please send schema & queries or we will not be able to help you. Also,
if you could
Rhaoni,
> My problem is that I must substitute this Oracle for a PostgreSQL
> database and this same Delphi aplication takes 45 min to update Jan/2003.
> All delphi routines are converted and optmized to work with PgSQL.
Obviously not.
How about posting the update queries?
--
Josh
20 matches
Mail list logo
