Andrus Moor wrote:
I have item table and a lot of child tables where the items are used.
I want to merge two item codes into single item in all tables.
It is not nice to write a lot of separate UPDATE statements for each table.
So I want to utilize REFERENCES clause for merging.
I tried the followi
Hello Scott,
Scott Marlowe wrote:
On Mon, 2005-03-28 at 15:43, T E Schmitz wrote:
How expensive would it be to maintain the following VIEW:
CREATE VIEW origin AS SELECT DISTINCT origin FROM transaktion
if there is in index on transaktion.origin; the table transaktion has
thousands of records and t
On Mar 29, 2005, at 5:07 AM, T E Schmitz wrote:
Hello Scott,
Scott Marlowe wrote:
On Mon, 2005-03-28 at 15:43, T E Schmitz wrote:
How expensive would it be to maintain the following VIEW:
CREATE VIEW origin AS SELECT DISTINCT origin FROM transaktion
if there is in index on transaktion.origin; the t
I 'll use a bound cursor with parameters.
But when I use such a cursor, I found a error.
I don't know error message.
How can I use a bound cursor.
in following sample, near a 'for loop' , error
found.
--
CR
On Tue, Mar 29, 2005 at 11:07:20 +0100,
T E Schmitz <[EMAIL PROTECTED]> wrote:
>
> Would the "SELECT DISTINCT origin" always cause a sequential table scan
> regardless whether there is an index on the origin column or not?
It's worse than that, SELECT DISTINCT cannot use a hash aggregate plan
Bruno Wolff III wrote:
On Tue, Mar 29, 2005 at 11:07:20 +0100,
T E Schmitz <[EMAIL PROTECTED]> wrote:
Would the "SELECT DISTINCT origin" always cause a sequential table scan
regardless whether there is an index on the origin column or not?
It's worse than that, SELECT DISTINCT cannot use a hash
On Tue, Mar 29, 2005 at 02:21:15PM +0100, T E Schmitz wrote:
> Bruno Wolff III wrote:
> >On Tue, Mar 29, 2005 at 11:07:20 +0100,
> > T E Schmitz <[EMAIL PROTECTED]> wrote:
> >
> >>Would the "SELECT DISTINCT origin" always cause a sequential table
> >>scan regardless whether there is an index on th
Alvaro Herrera wrote:
On Tue, Mar 29, 2005 at 02:21:15PM +0100, T E Schmitz wrote:
Bruno Wolff III wrote:
On Tue, Mar 29, 2005 at 11:07:20 +0100,
T E Schmitz <[EMAIL PROTECTED]> wrote:
Would the "SELECT DISTINCT origin" always cause a sequential table
scan regardless whether there is an index on t
On Tue, Mar 29, 2005 at 14:21:15 +0100,
T E Schmitz <[EMAIL PROTECTED]> wrote:
>
> As far as I can see (via EXPLAIN), both DISTINCT and GROUP BY will lead
> to a sequentail scan. Is that correct?
If you need to read the whole table yes. However if you join the view
to something else that might
On Tue, Mar 29, 2005 at 15:12:24 +0100,
T E Schmitz <[EMAIL PROTECTED]> wrote:
>
> Shall do.
> But am I correct in assuming that I should place an index on the group
> by (TRANSAKTION.ORIGIN) column?
This will mainly help when joining the view to another table. This would
also allow using an i
T E Schmitz <[EMAIL PROTECTED]> writes:
> As far as I can see (via EXPLAIN), both DISTINCT and GROUP BY will lead
> to a sequentail scan. Is that correct?
I'm not sure why you expect something different. The query requires
visiting every row of the table in any case --- else it might miss
values
Bruno Wolff III wrote:
On Tue, Mar 29, 2005 at 14:21:15 +0100,
T E Schmitz <[EMAIL PROTECTED]> wrote:
If that's the case, I should come up with a different concept to obtain
a list of ORIGINs.
That may be a good idea, especially if there are lots of rows for each
origin value.
That's what I wi
On Tue, Mar 29, 2005 at 08:49:49PM +0900, ?? wrote:
> I 'll use a bound cursor with parameters.
> But when I use such a cursor, I found a error.
> I don't know error message.
It's usually a good idea to post the error message. In most cases
it should say what's wrong, or at least where someth
13 matches
Mail list logo
