"Jim 'Decibel!' Nasby" <[EMAIL PROTECTED]> writes:
> So here's something odd... in both 8.3 and HEAD from a while ago it
> gives a better plan for SELECT * than for SELECT count(*):
The short answer is that the Subquery Scan nodes can be dropped out
when they are no-ops, which is to say producin
On Tue, Nov 11, 2008 at 4:00 PM, Vladimir Sitnikov
<[EMAIL PROTECTED]> wrote:
>
>> Yes, NULL values are not stored in the index, but you may create
>> functional index on
>
> Are you sure NULL values are not stored? btree, gist and bitmap index and
> search for NULL values.
It's not that they're n
> Yes, NULL values are not stored in the index, but you may create functional
> index on
>
Are you sure NULL values are not stored? btree, gist and bitmap index and
search for NULL values.
select amname, amindexnulls, amsearchnulls from pg_am;
amname | amindexnulls | amsearchnulls
+-
On Nov 11, 2008, at 1:15 PM, Tom Lane wrote:
"Jim 'Decibel!' Nasby" <[EMAIL PROTECTED]> writes:
On Nov 10, 2008, at 9:20 PM, Tom Lane wrote:
8.3 gets it right though.
Doesn't seem to for me... :/
Oh, I was looking at "select * from v2" not "select count(*) from v2".
HEAD is a bit smarter a
Index is not used for
is null
condition:
create index makse_dokumnr_idx on makse(dokumnr);
explain select
sum( summa)
from MAKSE
where dokumnr is null
"Aggregate (cost=131927.95..131927.96 rows=1 width=10)"
" -> Seq Scan on makse (cost=0.00..131927.94 rows=1 width=10)"
"F
Tom Lane <[EMAIL PROTECTED]> schrieb:
> "Andrus" <[EMAIL PROTECTED]> writes:
> > Index is not used for
> > is null
>
> > How to fix ?
>
> Update to something newer than 8.1 (specifically, you'll need 8.3).
Right. For my example in the other mail:
test=*# create index idx_foo on foo(i);
CREATE
Andrus <[EMAIL PROTECTED]> schrieb:
> Index is not used for
>
> is null
>
> condition:
>
> create index makse_dokumnr_idx on makse(dokumnr);
> explain select
> sum( summa)
> from MAKSE
> where dokumnr is null
>
> "Aggregate (cost=131927.95..131927.96 rows=1 width=10)"
> " -> Seq Scan
"Andrus" <[EMAIL PROTECTED]> writes:
> Index is not used for
> is null
> How to fix ?
Update to something newer than 8.1 (specifically, you'll need 8.3).
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to
Index is not used for
is null
condition:
create index makse_dokumnr_idx on makse(dokumnr);
explain select
sum( summa)
from MAKSE
where dokumnr is null
"Aggregate (cost=131927.95..131927.96 rows=1 width=10)"
" -> Seq Scan on makse (cost=0.00..131927.94 rows=1 width=10)"
"F
"Jim 'Decibel!' Nasby" <[EMAIL PROTECTED]> writes:
> On Nov 10, 2008, at 9:20 PM, Tom Lane wrote:
>> 8.3 gets it right though.
> Doesn't seem to for me... :/
Oh, I was looking at "select * from v2" not "select count(*) from v2".
HEAD is a bit smarter about the latter than 8.3 is.
On Nov 10, 2008, at 9:20 PM, Tom Lane wrote:
"Jim 'Decibel!' Nasby" <[EMAIL PROTECTED]> writes:
On Nov 10, 2008, at 1:31 PM, Tom Lane wrote:
On my machine this runs about twice as fast as the original view.
Am I missing some magic? I'm still getting the subquery scan.
Hmm, I'm getting a co
Seems like this didn't make it through to the list the first time...
* Aidan Van Dyk <[EMAIL PROTECTED]> [081106 22:19]:
> * David Rees <[EMAIL PROTECTED]> [081106 21:22]:
>
> > 2. A write barrier instructs the lower level hardware that commands
> > issued before the barrier must be written to d
On Thu, 6 Nov 2008, Scott Marlowe wrote:
Without write barriers, the second we call an fsync it returns true.
But that's assuming write barriers work as I understand them.
Write barriers do not work as you understand them.
Calling fsync always blocks until all the data has made it to safe
st
13 matches
Mail list logo
