On Wednesday 14 March 2007 22:59, Wiebe Cazemier wrote:
> My question was mainly general;
> if there is a better way than using subselects to join two tables which
> are only connected to eachother through a join-table (containing only
> references to the two tables in question). Subselects are us
On Thursday 15 March 2007 15:05, Rodrigo De León wrote:
> From http://www.postgresql.org/docs/8.2/static/indexes-types.html :
>
> "The optimizer can also use a B-tree index for queries involving the
> pattern matching operators LIKE and ~ if the pattern is a constant and
> is anchored to the begi
On 3/14/07, Wiebe Cazemier <[EMAIL PROTECTED]> wrote:
I discovered that removing the subselect (the entire second condition of
the join actually) is not the only thing that speeds it up. If I remove
the LIKE check on account.description, it's also a lot faster (152 ms
as opposed to 2915 ms), alth
On Wednesday 14 March 2007 18:58, Frank Bax wrote:
> A performance question should always include the output of EXPLAIN ANALYZE.
>
> I think the problem is database design. If you added a boolean column into
> accounts table which would indicate owner/co-owner; then all data from
> account_co_own
At 11:39 AM 3/14/07, Wiebe Cazemier wrote:
Consider this scenario of three (simplified) tables:
people
- id
- name
accounts
- id
- owner_id REFERENCES people
account_co_owners
- co_owner_id REFERENCES people
- account_id REFERENCES accounts
I need a query that allows the user to search for ac
Hi,
Doing a join on one-to-many relations (like "orders" joining "custumors") is
easy, but what if there are many-to-many relations involved?
Consider this scenario of three (simplified) tables:
people
- id
- name
accounts
- id
- owner_id REFERENCES people
account_co_owners
- co_owner_id REFER
