Hello Tore,
On 10/2/07, Tore Halset <[EMAIL PROTECTED]> wrote:
> Hello.
>
> This does not sound like a cayenne issue any more.
Definitely.
> Here is what I would do to get going.
>
> * Remove the extra OS layer if you are still using it. Was it
> Parallells?
Parallels could alter the absolut
Hello.
This does not sound like a cayenne issue any more. Here is what I
would do to get going.
* Remove the extra OS layer if you are still using it. Was it
Parallells?
* Update to latest PostgreSQL and JDBC driver.
* Use vacuum analyze and autovacuum
* Find slow queries and use "expl
Yes,
I have vacuumed it and also rebuild the indexes to no avail. :-(
I am not a PostgreSQL expert (and not even an expert DBA in general),
so it is very possible that I am doing something very wrong.
This is both a good news (the application should be fine, and I don't
need to tune it much furt
Have you vacuumed the original (slow) table?
/dev/mrg
On 10/1/07, Giulio Cesare Solaroli <[EMAIL PROTECTED]> wrote:
> Hello everybody,
>
> today I have being able to do some more tests and I have found out
> that the problem seems to be caused by a "fragmentation" of the data
> on the Postgresql
Hello everybody,
today I have being able to do some more tests and I have found out
that the problem seems to be caused by a "fragmentation" of the data
on the Postgresql table space.
I have created a copy of the table where delete statements where very
slow (using the "create table as selec
Hello,
I have collected a few more data, as suggested by Aristedes.
On 9/23/07, Giulio Cesare Solaroli <[EMAIL PROTECTED]> wrote:
> On 9/23/07, Aristedes Maniatis <[EMAIL PROTECTED]> wrote:
> >
> > On 23/09/2007, at 5:38 PM, Giulio Cesare Solaroli wrote:
> >
> > > log4j.logger.org.apache.cayenne=
On 9/23/07, Aristedes Maniatis <[EMAIL PROTECTED]> wrote:
>
> On 23/09/2007, at 5:38 PM, Giulio Cesare Solaroli wrote:
>
> > log4j.logger.org.apache.cayenne=ERROR
> > log4j.logger.org.apache.cayenne.access.QueryLogger=DEBUG
> >
> >
> > Is there anything going on on the Cayenne code between the last
On 23/09/2007, at 5:38 PM, Giulio Cesare Solaroli wrote:
log4j.logger.org.apache.cayenne=ERROR
log4j.logger.org.apache.cayenne.access.QueryLogger=DEBUG
Is there anything going on on the Cayenne code between the last [batch
bind:xxx] log and the "updated" log?
Well, you could always try:
lo
Hello Aristedes,
On 9/23/07, Aristedes Maniatis <[EMAIL PROTECTED]> wrote:
>
> On 22/09/2007, at 11:41 PM, Giulio Cesare Solaroli wrote:
>
> > 15 seconds are a lot of time, but they would be bearable. The problem
> > is that I suppose this time will gradually increase with the growth of
> > the nu
On 22/09/2007, at 11:41 PM, Giulio Cesare Solaroli wrote:
15 seconds are a lot of time, but they would be bearable. The problem
is that I suppose this time will gradually increase with the growth of
the number of records to delete.
That is still about 1000 times the duration I'd expect this t
Hello Andrus,
thank you very much for the pointers; I will start digging them soon.
Best regards,
Giulio Cesare
On 9/22/07, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
>
> On Sep 22, 2007, at 4:41 PM, Giulio Cesare Solaroli wrote:
> >
> >>> The SQL I am expecting Cayenne to generate would look
On Sep 22, 2007, at 4:41 PM, Giulio Cesare Solaroli wrote:
The SQL I am expecting Cayenne to generate would look like this:
delete from user_detail where id_user = ;
Cayenne 3.0M2 (yet unreleased) supports such functionality via an
EJBQL query, but maybe you don't need to do direct DB delet
On 9/22/07, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
>
> On Sep 21, 2007, at 7:45 PM, Giulio Cesare Solaroli wrote:
>
> >
> > [18:09:40] DELETE FROM clipperz.RCRVRS WHERE ID_RCRVRS = ?
> > [18:09:40] [batch bind: 968]
> > [18:09:40] [batch bind: 875]
> > [..]
> > [18:09:40] [batch bind: 1177]
Hello,
On 9/22/07, Michael Gentry <[EMAIL PROTECTED]> wrote:
> FWIW:
>
> I run PostgreSQL on OS X and it is plenty fast enough. The downside
> to PostgreSQL on OS X is there isn't an installer, so it is more work
> to build and install. If you are Unix-savvy, though, this won't be
> much of a pr
FWIW:
I run PostgreSQL on OS X and it is plenty fast enough. The downside
to PostgreSQL on OS X is there isn't an installer, so it is more work
to build and install. If you are Unix-savvy, though, this won't be
much of a problem.
I've used PostgreSQL on Windows, too, which works alright overall
On Sep 21, 2007, at 7:45 PM, Giulio Cesare Solaroli wrote:
[18:09:40] DELETE FROM clipperz.RCRVRS WHERE ID_RCRVRS = ?
[18:09:40] [batch bind: 968]
[18:09:40] [batch bind: 875]
[..]
[18:09:40] [batch bind: 1177]
[18:09:40] [batch bind: 2792]
[18:11:54] === updated 68 rows.
In this case, to
On 22/09/2007, at 2:45 AM, Giulio Cesare Solaroli wrote:
In this case, to delete just 68 rows it took more than two minutes,
but I don't know if this time is spent somewhere inside the cayenne
code, or if this is simply the time it took PostgreSQL to "physically"
delete the rows.
Do these deta
On Sep 21, 2007, at 9:45 AM, Giulio Cesare Solaroli wrote:
I have tried to attach the logs and the model to the message, but the
maililng list system has rejected it has spam. :-(
Apache has strong anti-spam controls in place for email.
You can open a jira issue and upload files to the issue
I have tried to attach the logs and the model to the message, but the
maililng list system has rejected it has spam. :-(
If the full log and/or model could be useful in understanding the
problem, I will upload them somewhere else.
Hello Aristedes,
thanks for your reply.
Before answering your q
On 22/09/2007, at 12:31 AM, Giulio Cesare Solaroli wrote:
When I try to delete an user, all the cascade rules are correctly
applied, but the all process takes about 7 minutes for a regular
account. This is much more than we can bear for any operation.
That does seem extraordinary. Can you giv
Hello everybody,
I am facing a performance bottle neck while commiting the dataContext
when many "cascade" rules are applied to relevant relationships.
This scenario is quite simple: in my db schema there is a core entity
that is the User; this entity has many subordinate information that
are col
21 matches
Mail list logo
