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
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
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
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
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
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 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
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 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
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 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
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
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
13 matches
Mail list logo
