Re: analyzing intermediate query

>>> My list can contain 1 .. 100000 records and table contains 3000000
>>> records and is growing.
>>
>> Ah. No IN(), then ;)
>> Temp table + ANALYZE seems your only option...
>
> In 8.3 or 8.4 I think that IN() or temp table produce exactly the same
> result.
>
> Andrus.

Oh, I just thought about something, I don't remember in which version it
was added, but :

EXPLAIN ANALYZE SELECT sum(column1) FROM (VALUES ...a million integers...
) AS v

Postgres is perfectly happy with that ; it's either a bit slow (about 1
second) or very fast depending on how you view things...

Aggregate (cost=15000.00..15000.01 rows=1 width=4) (actual
time=1060.253..1060.253 rows=1 loops=1)
-> Values Scan on "*VALUES*" (cost=0.00..12500.00 rows=1000000 width=4)
(actual time=0.009..634.728 rows=1000000 loops=1)
Total runtime: 1091.420 ms

The most interesting thing, of course, is that the statistics are exact.
You can use VALUES like a table (Join, whatever).
Of course it's always slightly annoying to juggle around with result sets
and stuff them in comma-separated strings, but it works.

Here it knows there's few rows ===> nested loop

EXPLAIN SELECT a.* FROM annonces a JOIN (VALUES
(0),(1),(2),(3),(4),(5),(6),(7)) AS v ON (a.id=v.column1);
QUERY PLAN
----------------------------------------------------------------------------------------
Nested Loop (cost=0.00..66.73 rows=8 width=943)
-> Values Scan on "*VALUES*" (cost=0.00..0.10 rows=8 width=4)
-> Index Scan using annonces_pkey on annonces a (cost=0.00..8.32
rows=1 width=943)
Index Cond: (a.id = "*VALUES*".column1)

With a million values it goes hash of course, etc.