Re: [PERFORM] Planner question - "bit" data types

2009-09-05 Thread Merlin Moncure
On Sat, Sep 5, 2009 at 8:19 PM, Karl Denninger wrote: > There was a previous thread and I referenced it. I don't have the other one > in my email system any more to follow up to it. > > I give up; the attack-dog crowd has successfully driven me off.  Ciao. Another more standard sql approach is to

Re: [PERFORM] Planner question - "bit" data types

2009-09-05 Thread Karl Denninger
There was a previous thread and I referenced it. I don't have the other one in my email system any more to follow up to it. I give up; the attack-dog crowd has successfully driven me off. Ciao. Alvaro Herrera wrote: > Karl Denninger escribió: > >> Tom Lane wrote: >> > > >>> You never

Re: [PERFORM] Planner question - "bit" data types

2009-09-05 Thread Alvaro Herrera
Karl Denninger escribió: > Tom Lane wrote: > > You never showed us any EXPLAIN results, > Yes I did. Go back and look at the archives. I provided full EXPLAIN > and EXPLAIN ANALYZE results for the original query. Sheesh. You did? Where? This is your first message in this thread: http://archi

Re: [PERFORM] Planner question - "bit" data types

2009-09-05 Thread Karl Denninger
Tom Lane wrote: > Karl Denninger writes: > >> Tom Lane wrote: >> >>> In that case you'd be wasting your time to get it to use an index >>> for the condition anyway. Maybe you need to take a step back and >>> look at the query as a whole rather than focus on this particular >>> condition.

Re: [PERFORM] Planner question - "bit" data types

2009-09-05 Thread Tom Lane
Karl Denninger writes: > Tom Lane wrote: >> In that case you'd be wasting your time to get it to use an index >> for the condition anyway. Maybe you need to take a step back and >> look at the query as a whole rather than focus on this particular >> condition. > The query, sans this condition, i

Re: [PERFORM] Planner question - "bit" data types

2009-09-05 Thread Karl Denninger
Tom Lane wrote: > Karl Denninger writes: > >> That doesn't help in this case as the returned set will typically be >> quite large, with the condition typically being valid on anywhere from >> 10-80% of the returned tuples. >> > > In that case you'd be wasting your time to get it to use an

Re: [PERFORM] Planner question - "bit" data types

2009-09-05 Thread Tom Lane
Karl Denninger writes: > That doesn't help in this case as the returned set will typically be > quite large, with the condition typically being valid on anywhere from > 10-80% of the returned tuples. In that case you'd be wasting your time to get it to use an index for the condition anyway. Mayb

Re: [PERFORM] Planner question - "bit" data types

2009-09-05 Thread Karl Denninger
Tom Lane wrote: > Merlin Moncure writes: > >> If you are only interested in one or a very small number of cases of >> 'permission', you can use an expression index to target constant >> values: >> > > >> "select ... from where .. and (permission & mask = permission)" >> >

Re: [PERFORM] Planner question - "bit" data types

2009-09-05 Thread Tom Lane
Merlin Moncure writes: > If you are only interested in one or a very small number of cases of > 'permission', you can use an expression index to target constant > values: > "select ... from where .. and (permission & mask = permission)" > create index foo_permission_xyz_idx on foo((64 &

Re: [PERFORM] Planner question - "bit" data types

2009-09-05 Thread Merlin Moncure
On Fri, Sep 4, 2009 at 6:29 PM, Josh Berkus wrote: > Karl, > >> For reference, I was having SEVERE performance problems with the >> following comparison in an SQL statement where "mask" was an integer: >> >> "select ... from where .. and (permission & mask = permission)" > > AFAIK, the onl