Hi,
I think the query planner is unaware of the possibly best plan in some
situations. See the test case below:
-- --- --
CREATE TABLE tparent (
id integer NOT NULL,
ord integer NOT NULL,
CONSTRAINT par_pkey_id PRIMARY KEY (id),
CONSTRAINT
Tom Lane <[EMAIL PROTECTED]> wrote:
> Dániel Dénes <[EMAIL PROTECTED]> writes:
> > But even then, it won't realize that the result are in correct
> > order, and does a sort! Why?
>
> In general the output of a nestloop doesn't derive any ordering
Hi,
I've got a table that stores private messages (like e-mails). Every row
has a source_user, a destination_user, a timestamp, and information
on whether the source and/or the destination user has already deleted
the message.
> CREATE TABLE privs (
> id serial NOT NULL,
> src_usrid integer
Tom Lane <[EMAIL PROTECTED]> írta:
> Daniel Denes <[EMAIL PROTECTED]> writes:
> > But even then, it won't realize that the result are in correct order,
> > and does a sort! Why?
>
> In general the output of a nestloop doesn't derive any ordering
> properties from the inner scan. It might happen
Hi,
I have three tables involved in my problem:
forums_grps [means: Forum-Groups]
- id (PRIMARY KEY)
- title
forums [means: Forums]
- id (PRIMARY KEY)
- forum_group_id (NOT NULL, FOREIGN KEY)
- order (defines listing order of forums in the same forum_group)
INDEX: (forum_group_id, order)
sit_sh
Tom Lane <[EMAIL PROTECTED]> wrote:
> Daniel Denes <[EMAIL PROTECTED]> writes:
>
> > But what if I try like
> >> SELECT * FROM mytable
> >> WHERE not_unique_col = 41 ORDER BY pri_key ASC FOR UPDATE;
> > and do the UPDATE after this? It should never lead to a deadlock,
> > assuming the rows sel
Hi,
My problem is that if I try to update more than one row in a table like
> UPDATE mytable SET something = 84 WHERE not_unique_col = 41;
in two concurrent transactions, it can result in a deadlock if the two
UPDATEs visit the rows in a different order.
The same applies, if I try to
> SELECT * F
