Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Thu, 23 Jan 2003, Tom Lane wrote:
>> What I was thinking was that any time the code sees a "var = const"
>> clause as part of a mergejoin equivalence set, we could mark all the
>> "var = var" clauses in the same set as no-ops. For example, given
>> WH
On Thu, 23 Jan 2003, Tom Lane wrote:
> regression=# explain analyze select * from tenk1 a join tenk1 b using(ten)
> regression-# where ten = 3;
> QUERY PLAN
>
>--
On Thu, Jan 23, 2003 at 08:53:53AM -0800, Stephan Szabo wrote:
> On Wed, 22 Jan 2003, Tom Lane wrote:
>
> I haven't looked at code yet but tried examples like Tomasz's and some
> simple ones and have gotten reasonable seeming output for the estimates
> given accurate statistics (joining two estima
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 22 Jan 2003, Tom Lane wrote:
>> It could still use more eyeballs looking at it. One thing I'm concerned
>> about is whether the extra (derived) conditions lead to double-counting
>> restrictivity and thus underestimating the number of result rows
On Wed, 22 Jan 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Wed, 22 Jan 2003, Tom Lane wrote:
> >> Stephan Szabo <[EMAIL PROTECTED]> writes:
> >>> The filter is applied only to a. So, if you really wanted the
> >>> c.a=3 condition to be applied for whatever reason you'
Ries van Twisk wrote:
First of all I want to thank you for all responses! I was overwhelmed with
it :D
Below you find the schema I'm currently using and the output of explain. I
removed all comments so the mail will be small, the schema is still work in
progress. I especially I need to take a loo
u een volgt nummer
-- newcableno zal ALTIJD <= 998 zijn en dus altijd maar 3 positie innemen
newcableno=newcableno+1;
IF prefix != '''' THEN
cablename = prefix || ''.'' || lpad(newcableno, 3, ''0'');
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 22 Jan 2003, Tom Lane wrote:
>> Stephan Szabo <[EMAIL PROTECTED]> writes:
>>> The filter is applied only to a. So, if you really wanted the
>>> c.a=3 condition to be applied for whatever reason you're out of
>>> luck.
>>
>> FWIW, CVS tip is brig
On Wed, 22 Jan 2003, Tomasz Myrta wrote:
> Stephan Szabo wrote:
>
> >That's not the same join for optimization purposes
> >since postgresql treats explicit join syntax as a
> >constraint on the ordering of joins.
> >
> >The same join would be something like:
> >
> >przystanki p1 join miasta m1 usi
On Wed, 22 Jan 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > The filter is applied only to a. So, if you really wanted the
> > c.a=3 condition to be applied for whatever reason you're out of
> > luck.
>
> FWIW, CVS tip is brighter: the condition does propagate to both re
Stephan Szabo wrote:
That's not the same join for optimization purposes
since postgresql treats explicit join syntax as a
constraint on the ordering of joins.
The same join would be something like:
przystanki p1 join miasta m1 using (id_miasta)
join (przystanki p2 join miasta m2 using (id_miast
Stephan Szabo <[EMAIL PROTECTED]> writes:
> ... but this is a general transitivity constraint AFAIK, not
> one actually to do with views (ie, if you wrote out the query without a
> view, you can run into the same issue). It's somewhat easier to run into
> the case with views and the effect may be
On Wed, 22 Jan 2003, Tomasz Myrta wrote:
> Let's make some test:
>
> First, let's create some simple view with 2 tables join:
> drop view pm;
> create view pm as
> select
>id_przystanku,
>m.nazwa
> from
>przystanki p
>join miasta m using (id_miasta);
>
> explain select * from pm
Stephan Szabo wrote:
On Wed, 22 Jan 2003, Tomasz Myrta wrote:
Tomasz Myrta writes:
I'd like to split queries into views, but I can't join them - planner
search all of records instead of using index. It works very slow.
I think this is the same issue that Stephan identified in his response
Stephan Szabo wrote:
On Wed, 22 Jan 2003, Tomasz Myrta wrote:
Tomasz Myrta writes:
I'd like to split queries into views, but I can't join them - planner
search all of records instead of using index. It works very slow.
I think this is the same issue that Stephan identified in his response
Tomasz Myrta wrote:
>
> Jan Wieck wrote:
>
> >Use tables, views and views over views, it's all fine and your indexes
> >will be used.
>
> I can't agree with using views over views. It has some limitations.
> I asked about it on this list several months ago
> and Tom Lane's conclusion was:
It ha
On Wed, 22 Jan 2003, Tomasz Myrta wrote:
> >> Tomasz Myrta <[EMAIL PROTECTED]> writes:
> >> I'd like to split queries into views, but I can't join them - planner
> >> search all of records instead of using index. It works very slow.
>
>
> I think this is the same issue that Stephan identified in h
Jan Wieck wrote:
Use tables, views and views over views, it's all fine and your indexes
will be used.
I can't agree with using views over views. It has some limitations.
I asked about it on this list several months ago
and Tom Lane's conclusion was:
Tomasz Myrta <[EMAIL PROTECTED]> writes:
I
On Wed, 22 Jan 2003, Ries van Twisk wrote:
> Dear PostgreSQL users,
>
> I have a view and a table,
>
> I understand that when a frontend accesses a VIEW that PostgreSQL cannot use
> a index on that view.
> For example when I do this: SELECT * FROM full_cablelist WHERE
> projectocode=5; Correct?
Ries van Twisk wrote:
Dear PostgreSQL users,
I have a view and a table,
I understand that when a frontend accesses a VIEW that PostgreSQL cannot use
a index on that view.
For example when I do this: SELECT * FROM full_cablelist WHERE
projectocode=5; Correct?
Now I just want to make sure for my
Ries van Twisk wrote:
>
> Dear PostgreSQL users,
>
> I have a view and a table,
>
> I understand that when a frontend accesses a VIEW that PostgreSQL cannot use
> a index on that view.
> For example when I do this: SELECT * FROM full_cablelist WHERE
> projectocode=5; Correct?
No.
>
> Now I j
On Wed, Jan 22, 2003 at 16:12:52 +0100,
Ries van Twisk <[EMAIL PROTECTED]> wrote:
> Dear PostgreSQL users,
>
> I understand that when a frontend accesses a VIEW that PostgreSQL cannot use
> a index on that view.
> For example when I do this: SELECT * FROM full_cablelist WHERE
> projectocode=5; C
Dear PostgreSQL users,
I have a view and a table,
I understand that when a frontend accesses a VIEW that PostgreSQL cannot use
a index on that view.
For example when I do this: SELECT * FROM full_cablelist WHERE
projectocode=5; Correct?
Now I just want to make sure for myself if the VIEW I creat
23 matches
Mail list logo
