-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/14/07 06:43, Ray Bannon wrote:
> There is only one table/view, it's getting one record for each of the
Clarity in question-asking always helps.
> hundred or so plan ID's that I'm looking for.
One table, huh? Then why all the references to "RO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ever considered using a materialized view? If you do, you could write
the code to load/sync your materialized view using a FOR loop. Note that
PostgreSQL does not support materialized views out of the box, so you'd
need to play around with some trigger
There is only one table/view, it's getting one record for each of the
hundred or so plan ID's that I'm looking for.
On 2/13/07 11:29 PM, in article [EMAIL PROTECTED], "Ron Johnson"
<[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/13/07 07:46, Ray Bannon wro
On Tue, 2007-02-13 at 05:46 -0800, Ray Bannon wrote:
> Select ID, plan_name from table/view
> Where plan_name = 'A'
> And rownum = 1
> UNION
...
>
> Ad infinitum for about 100 iterations.
>
> Any way to write this more efficiently?
I assume that "table/view" in your OP really refers to diffe
Ray Bannon <[EMAIL PROTECTED]> writes:
> Any way to write this more efficiently?
UNION -> UNION ALL, perhaps? Do you really need UNION's duplicate-row-
elimination behavior?
regards, tom lane
---(end of broadcast)---
TIP 3:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/13/07 07:46, Ray Bannon wrote:
> I have a query which is running a bit slowly, and I'm wondering if anyone
> has a design improvement. Basically it's a series of unions as follows:
>
> Select ID, plan_name from table/view
> Where plan_name = 'A'
Ray Bannon wrote:
I have a query which is running a bit slowly, and I'm wondering if anyone
has a design improvement. Basically it's a series of unions as follows:
Select ID, plan_name from table/view
Where plan_name = 'A'
And rownum = 1
UNION
Select ID, plan_name from table/view
Where plan_name
I have a query which is running a bit slowly, and I'm wondering if anyone
has a design improvement. Basically it's a series of unions as follows:
Select ID, plan_name from table/view
Where plan_name = 'A'
And rownum = 1
UNION
Select ID, plan_name from table/view
Where plan_name = 'B'
And rownum =
On Wed, Oct 20, 2004 at 01:54:04PM +0200, Sim Zacks wrote:
> It is very weird, I just tried both a group by and distinct and both
> of them still return the duplicates.
>
> I also tried a very simple union which didn't return any duplicates,
> both of these said, it is obviously not a problem with
double precision is inexact and therefore any query returning a field
of that type cannot be in a group by/distinct...
I switched it to type ::numeric(10,4) and it worked fine.
It was the system that automatically did the conversion for me, so I
will have to figure out why and keep that in mind f
It is very weird, I just tried both a group by and distinct and both
of them still return the duplicates.
I also tried a very simple union which didn't return any duplicates,
both of these said, it is obviously not a problem with union.
I just tried the query without the case statement that does
I am using 8.0 beta 1 on an RH 8 Linux server.
I have a union query that I am converting from access (where it
worked) and it is returning duplicates. The only difference between
the two rows is the Row field, which is returned automatically.
and an example of a row that it has returned duplicate
"Tamsin" <[EMAIL PROTECTED]> writes:
>select 'other' union select description from address;
>ERROR: Unable to transform varchar to unknown
> Each UNION | EXCEPT | INTERSECT clause must have compatible target
> types
The behavior in 7.0.* and before (as far back as I recall) has b
Just spent an hour getting nowhere, til I discovered this (description is a
varchar field):
select description from address union select 'other';
fine but...
select 'other' union select description from address;
ERROR: Unable to transform varchar to unknown
Each UNION | EXCEP
14 matches
Mail list logo
