"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 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
"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
"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 core dump :-( ... this seems to be busted in HE
On Nov 10, 2008, at 1:31 PM, Tom Lane wrote:
"Jim 'Decibel!' Nasby" <[EMAIL PROTECTED]> writes:
Here's the commands to generate the test case:
create table a(a int, b text default 'test text');
create table c(c_id serial primary key, c_text text);
insert into c(c_text) values('a'),('b'),('c')
"Jim 'Decibel!' Nasby" <[EMAIL PROTECTED]> writes:
> Here's the commands to generate the test case:
> create table a(a int, b text default 'test text');
> create table c(c_id serial primary key, c_text text);
> insert into c(c_text) values('a'),('b'),('c');
> create table b(a int, c_id int referen
On Nov 10, 2008, at 12:21 PM, Richard Huxton wrote:
Jim 'Decibel!' Nasby wrote:
On Nov 10, 2008, at 7:06 AM, Tom Lane wrote:
"Jim 'Decibel!' Nasby" <[EMAIL PROTECTED]> writes:
loan_tasks effectively does SELECT * FROM loan_tasks_committed
UNION
ALL SELECT * FROM loan_tasks_pending;.
You se
"Jim 'Decibel!' Nasby" <[EMAIL PROTECTED]> writes:
> How on earth did the seqscan suddenly take 4x longer? And why is the
> subquery scan then doubling the amount of time again?
Maybe the disk access is less sequential because of the need to fetch
the other table too?
re
Jim 'Decibel!' Nasby wrote:
> On Nov 10, 2008, at 7:06 AM, Tom Lane wrote:
>> "Jim 'Decibel!' Nasby" <[EMAIL PROTECTED]> writes:
>>> loan_tasks effectively does SELECT * FROM loan_tasks_committed UNION
>>> ALL SELECT * FROM loan_tasks_pending;.
>>
>> You seem to have neglected to mention a join or
On Nov 10, 2008, at 7:06 AM, Tom Lane wrote:
"Jim 'Decibel!' Nasby" <[EMAIL PROTECTED]> writes:
loan_tasks effectively does SELECT * FROM loan_tasks_committed UNION
ALL SELECT * FROM loan_tasks_pending;.
You seem to have neglected to mention a join or two.
Yeah, though I did show them at th
"Jim 'Decibel!' Nasby" <[EMAIL PROTECTED]> writes:
> loan_tasks effectively does SELECT * FROM loan_tasks_committed UNION
> ALL SELECT * FROM loan_tasks_pending;.
You seem to have neglected to mention a join or two.
regards, tom lane
--
Sent via pgsql-performance maili
Why is this view 9x slower than the base table?
[EMAIL PROTECTED] explain analyze select count(*) from
loan_tasks_committed;
QUERY PLAN
---
13 matches
Mail list logo
