Chris Cheston wrote:
HI all, I'm trying to implement a highly-scalable, high-performance,
real-time database replication system to back-up my Postgres database
as data gets written.
So far, Mammoth Replicator is looking pretty good but it costs $1000+ .
Yes but it includes 30 days of support and
Josh Berkus wrote:
> Pierre,
>
> > Are there any plans in a future Postgresql version to support a special
> > fsync method for Reiser4 which will use the filesystem's transaction
> > engine, instead of an old kludge like fsync(), with a possibility of
> > vastly enhanced performance ?
>
Pierre-Frédéric Caillaud wrote:
> Is there also a possibility to tell Postgres : "I don't care if I lose 30
> seconds of transactions on this table if the power goes out, I just want
> to be sure it's still ACID et al. compliant but you can fsync less often
> and thus be faster" (with a
HI all, I'm trying to implement a highly-scalable, high-performance,
real-time database replication system to back-up my Postgres database
as data gets written.
So far, Mammoth Replicator is looking pretty good but it costs $1000+ .
Has anyone tried Slony-I and other replication systems? Slony
Aaron,
> We are getting this error for other index's including primary key indexs
where we get OID page not found errors and the index corruption as posted
above.
> Sometimes when the index is broken it will cause run away searches which eat
up all the memory and the server needs to be restarte
"borajetta" <[EMAIL PROTECTED]> writes:
> We are getting this error for other index's including primary key indexs wh=
> ere we get OID page not found errors and the index corruption as posted abo=
> ve.
> Sometimes when the index is broken it will cause run away searches which ea=
> t up all the m
select count(*) FROM items_2004_07_29 as items
WHERE true AND index @@ to_tsquery('default', '( audiovox)') ; count
--- 4(1 row)
aers=# reindex index
idx_title_2004_07_29;REINDEXaers=# select count(*) FROM items_2004_07_29
as items WHERE true AND index @@ to_tsquery('default', '(
Arash Zaryoun wrote:
Hi Richard,
Thanks for your prompt reply. It fixed the problem.
Just one more question: Do I need to create an index for FKs?
You don't _need_ to, but on the referring side (e.g. table GCTBALLOT in
your example) PostgreSQL won't create one automatically.
Of course, the prim
> There is also the fact that NTFS is a very slow filesystem, and
> Linux is
> a lot better than Windows for everything disk, caching and IO related. Try
> to copy some files in NTFS and in ReiserFS...
I'm not so sure I would agree with such a blanket generalization. I find NTFS to be
very
Arash,
> We are having a performance problem with our database. The problem
> exists when we include a constraint in GCTBALLOT. The constraint is as
> follows:
You posted twice, to three different mailing lists each time. This is
discourteous. Please do not do so again, as people may not help
Pierre,
> Are there any plans in a future Postgresql version to support a special
> fsync method for Reiser4 which will use the filesystem's transaction
> engine, instead of an old kludge like fsync(), with a possibility of
> vastly enhanced performance ?
I don't know of any such in p
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Rod Taylor <[EMAIL PROTECTED]> wrote:
>> It is likely that you are missing an index on one of those foreign key'd
>> items.
> I don't think that is too likely as a foreign key reference must be a
> unique key which would have an index. I think the ty
What caught my attention initially was the 300+/sec insert performance.
On 8.0/NTFS/fsync=on, I can't break 100/sec on a 10k rpm ATA disk. My
hardware seems to be more or less in the same league as psql's, so I was
naturally curious if this was a NT/Unix issue, a 7.4/8.0 issue, or a
combination o
ReiserFS 4 is (will be) a filesystem that implements transactions.
Are there any plans in a future Postgresql version to support a special
fsync method for Reiser4 which will use the filesystem's transaction
engine, instead of an old kludge like fsync(), with a possibility of
vastly
> > It is likely that you are missing an index on one of those foreign
> > key'd items.
>
> I don't think that is too likely as a foreign key reference
> must be a unique key which would have an index.
I think you must be thinking of primary keys, not foreign keys. All
one-to-many relationshi
On Fri, Aug 13, 2004 at 17:17:10 +0100,
Matt Clark <[EMAIL PROTECTED]> wrote:
> > > It is likely that you are missing an index on one of those foreign
> > > key'd items.
> >
> > I don't think that is too likely as a foreign key reference
> > must be a unique key which would have an index.
>
Arash Zaryoun wrote:
Hi,
We are having a performance problem with our database. The problem
exists when we include a constraint in GCTBALLOT. The constraint is as
follows:
alter table GCTBALLOT
add constraint FK_GCTBALLOT_GCTWEBU foreign key (GCTWEBU_SRL)
references GCTWEBU (SRL)
on
Hi All,
We are having a performance problem with our database. The problem
exists when we include a constraint in GCTBALLOT. The constraint is as
follows:
alter table GCTBALLOT
add constraint FK_GCTBALLOT_GCTWEBU foreign key (GCTWEBU_SRL)
references GCTWEBU (SRL)
on delete restrict
>> OSDL did some testing and found Ext3 to be perhaps the worst FS for
>> PostgreSQL
>> -- although this testing was with the default options. Ext3 involved
> an
>> almost 40% write performance penalty compared with Ext2, whereas the
>> penalty
>> for ReiserFS and JFS was less than 10%.
>>
>> Thi
> Guys, just so you know:
>
> OSDL did some testing and found Ext3 to be perhaps the worst FS for
> PostgreSQL
> -- although this testing was with the default options. Ext3 involved an
> almost 40% write performance penalty compared with Ext2, whereas the
> penalty
> for ReiserFS and JFS was less
William Yu wrote:
> Rory Campbell-Lange wrote:
>
>> The present server is a 2GHz Pentium 4/512 KB cache with 2
>> software-raided ide disks (Maxtors) and 1GB of RAM.
>>
>>
>> I have been offered the following 1U server which I can just about
>> afford:
>>
>> 1U server
>> Intel Xeon 2.8GHz 512K
On Fri, Aug 13, 2004 at 08:57:56 -0400,
Rod Taylor <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-08-13 at 08:10, Ulrich Wisser wrote:
> > Hi,
> >
> > my inserts are done in one transaction, but due to some foreign key
> > constraints and five indexes sometimes the 100 inserts will take more
> > th
Hi,
We are having a performance problem with our database. The problem
exists when we include a constraint in GCTBALLOT. The constraint is as
follows:
alter table GCTBALLOT
add constraint FK_GCTBALLOT_GCTWEBU foreign key (GCTWEBU_SRL)
references GCTWEBU (SRL)
on delete restrict on
On Fri, 2004-08-13 at 08:10, Ulrich Wisser wrote:
> Hi,
>
> my inserts are done in one transaction, but due to some foreign key
> constraints and five indexes sometimes the 100 inserts will take more
> than 5 minutes.
It is likely that you are missing an index on one of those foreign key'd
item
On 13/08/2004 13:10 Ulrich Wisser wrote:
Hi,
my inserts are done in one transaction, but due to some foreign key
constraints and five indexes sometimes the 100 inserts will take more
than 5 minutes.
Two possibilities come to mind:
a) you need an index on the referenced FK field
b) you have an ind
Hi,
my inserts are done in one transaction, but due to some foreign key
constraints and five indexes sometimes the 100 inserts will take more
than 5 minutes.
/Ulrich
---(end of broadcast)---
TIP 6: Have you searched our list archives?
From: "G u i d o B a r o s i o" <[EMAIL PROTECTED]>:
> As I see it's 100 inserts every 5 minutes, not only 100 inserts.
>
> Sure it's extreme for only 100 inserts.
I am sorry, I do not quite grasp what you are saying.
my understanding was that there are constantly new inserts,
coming in bursts o
As I see it's 100 inserts every 5 minutes, not only 100 inserts.
Sure it's extreme for only 100 inserts.
Cheers,
Guido
> "G u i d o B a r o s i o" <[EMAIL PROTECTED]> wrote:
>
> [speeding up 100 inserts every 5 minutes]
>
> > Tips!
> > *Delete indexes and recreate them after the insert.
>
> s
"G u i d o B a r o s i o" <[EMAIL PROTECTED]> wrote:
[speeding up 100 inserts every 5 minutes]
> Tips!
> *Delete indexes and recreate them after the insert.
sounds a bit extreme, for only 100 inserts
gnari
---(end of broadcast)---
TIP 9: the
Tips!
*Delete indexes and recreate them after the insert.
*Disable auto-commit
*Perform a copy will be faster, sure.
Best wishes,
Guido
> Hi,
>
> is there anything I can doo to speed up inserts? One of my tables gets
> about 100 new rows every five minutes. And somehow the inserts tend to
> ta
Hi,
is there anything I can doo to speed up inserts? One of my tables gets
about 100 new rows every five minutes. And somehow the inserts tend to
take more and more time.
Any suggestions welcome.
TIA
Ulrich
---(end of broadcast)---
TIP 9: the plann
31 matches
Mail list logo
