"Ezequias Rodrigues da Rocha" <[EMAIL PROTECTED]> writes:
> The selection takes less than 1 second but on delete I wait more than 4
> minutes and notthing. Can someone tell me what could happen ?
Perhaps foreign keys referencing this table and no indexes on the
referencing columns? You're not req
On Fri, Oct 06, 2006 at 03:10:01PM -0300, Ezequias Rodrigues da Rocha wrote:
>
> BEGIN WORK;
> delete from base.ticket where session_id = 17 and cash_id = 99 and promo_id
> = 5;
> COMMIT WORK;
Try putting EXPLAIN ANALYSE on the beginning to see what's going on.
That said. . .
> I just think it
On Tue, Oct 03, 2006 at 14:44:12 -0700,
chester c young <[EMAIL PROTECTED]> wrote:
> My server is based MST, but web clients from Maine to Hawaii, and they wish
> to see timestamps based in their own locale.
>
> Can anyone tell me how they're handling this? (sorry - can't get rid of my
> clie
Hi list,I am having many problems to delete a table with only 19000 rows.The selection takes less than 1 second but on delete I wait more than 4 minutes and notthing. Can someone tell me what could happen ?
I tryed only one transaction but it does not work too:BEGIN WORK;
delete from base.ticket wh
Oh that's sweet and all I needed anyway thanks.
On Oct 6, 2006, at 12:25 PM, Tom Lane wrote:
Note that you can select "FOR UPDATE OF a" in this situation, it's
just
the B side that is problematic.
James Robinson
Socialserve.com
---(end of broadcast)---
James Robinson <[EMAIL PROTECTED]> writes:
> select a.id, b.id from foo a left outer join bar b on (b.a_id =
> a.id) for update;
> SELECT FOR UPDATE/SHARE cannot be applied to the nullable side of an
> outer join
> Is this behavior spec-mandated, or could only the rows in B which are
>
Given something like:
create table foo (id int primary key not null);
create table bar (id int primary key not null, a_id int references
foo(id));
select a.id, b.id from foo a left outer join bar b on (b.a_id =
a.id) for update;
PG 8.1.4 balks, saying:
SELECT FOR UPDATE/SHARE can
Great, it's nice to see that this might get rolled into one of the next
releases. Thanks,
Graham.
Tom Lane wrote:
Michael Glaesemann <[EMAIL PROTECTED]> writes:
Considering how late it is in the cycle, perhaps the change in
behavior should come in 8.3.
Yeah, there's not really e
On Fri, 6 Oct 2006, Jean-Paul Argudo wrote:
> Hi all,
>
> > Where did you get that idea? age's reference point is current_date (ie,
> > midnight) not now(). There are also some differences in the calculation
> > compared to a plain timestamp subtraction.
>
> I'm jumping on this thread to point o
Hi all,
> Where did you get that idea? age's reference point is current_date (ie,
> midnight) not now(). There are also some differences in the calculation
> compared to a plain timestamp subtraction.
I'm jumping on this thread to point out a little strange thing to me.
CURRENT_DATE, converted
10 matches
Mail list logo
