I've never seen this before.
Is this PG specific or generic SQL that I've never been exposed to?
On Apr 6, 2007, at 10:08 AM, Listmail wrote:
>
>
>> I have a choice of running:
>>
>> SELECT bar FROM tokens WHERE foo IN
>> ('apple','orange','biscuit'....) for up to ~300 words
>>
>> OR
>>
>> SELECT bar FROM tokens WHERE foo = 'apple' up to ~300 times as a
>> prepared/cached SQL statements.
>
> With new PG versions you can also use VALUES which will save you a
> hash if you know your keys are unique.
> Example use integers but you can use anything. Just like a normal
> join from a table.
> Putting 300 values in VALUES is certainly a LOT faster than doing
> 300 individual SELECTs !
>
> test=> EXPLAIN ANALYZE SELECT t.* FROM test t, ( VALUES (1),(2) )
> AS v WHERE t.id=v.column1;
> QUERY PLAN
> ----------------------------------------------------------------------
> --------------------------------------------------
> Nested Loop (cost=0.00..16.76 rows=2 width=8) (actual
> time=0.029...0.039 rows=2 loops=1)
> -> Values Scan on "*VALUES*" (cost=0.00..0.03 rows=2 width=4)
> (actual time=0.004..0.005 rows=2 loops=1)
> -> Index Scan using test_pkey on test t (cost=0.00..8.36
> rows=1 width=8) (actual time=0.013..0.015 rows=1 loops=2)
> Index Cond: (t.id = "*VALUES*".column1)
> Total runtime: 0.085 ms
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
