Tom Lane wrote:
where (flow_direction, dataset_id) in (select * from new_func(122))
Is this form of multi-column IN mentioned anywhere in the docs? I can't
find it.
Svenne
smime.p7s
Description: S/MIME Cryptographic Signature
Hi there.
I have hit a edge in the planning and I hope you can help.
The system uses a lot of stored procedures to move as much of the
intelligence into the database layer as possible.
My (development) query looks like and runs reasonably fast:
explain analyze select dataset_id, entity, sum(
Tom Lane wrote:
Svenne Krap <[EMAIL PROTECTED]> writes:
create view ord_institutes_sum as
SELECT ord_property_type_all.dataset_id, ord_property_type_all.nb_property_type_id, 0 AS institut, sum(ord_property_type_all.amount) AS amount
FROM ord_property_type_all
GR
time=0.004..0.019 rows=8
loops=1)
Total runtime: 43.297 ms
(28 rows)
Now, the whole question becomes, how do I get the planner to make a
better estimation of the returned rows.
I am not sure, I can follow your moving-the-union-all-further-out
advice, as I see no different place for the
Hi there.
I have tried to implement the layered views as suggested earlier on one
of the simplest queries (just to get a feel for it). And there seems to
be something odd going on.
Attached are all the statemens needed to see, how the database is made
and the contents of postgresql.conf and
Tom Lane wrote:
There's been some discussion of inline-expanding SQL functions that
return sets when they are called in FROM, which would make a SQL
function that contains just a SELECT effectively equivalent to a view
as far as the planner's powers of optimization go. No one's tried to
make it
nne
Richard Huxton wrote:
Svenne Krap wrote:
Hi there.
I am currently building a system, where it would be nice to use
multiple levels of views upon each other (it is a staticstics system,
where traceability is important).
Is there any significant performance reduction in say 10 levels of
v
Hi there.
I am currently building a system, where it would be nice to use multiple
levels of views upon each other (it is a staticstics system, where
traceability is important).
Is there any significant performance reduction in say 10 levels of views
instead of one giant, nested sql-statemen
