Scott Marlowe writes:
> On Tue, Apr 5, 2011 at 1:25 PM, Maria L. Wilson
> wrote:
> This bit:
>> left outer join INVENTORY IV on GV.GRANULE_ID = IV.GRANULE_ID, INVSENSOR
>> INVS
> has both an explicit and an implicit join. This can constrain join
> re-ordering in the planner. Can you change it
On Tue, May 10, 2011 at 2:20 PM, Maria L. Wilson
wrote:
> haven't tested a composite index
>
> invsensor is 2,003,980 rows and 219MB
> granver is 5,138,730 rows and 556MB
> the machine has 32G memory
> seq_page_cost, random_page_costs & effective_cache_size are set to the
> defaults (1,4, and 128M
On Tue, Apr 5, 2011 at 1:25 PM, Maria L. Wilson
wrote:
This bit:
> left outer join INVENTORY IV on GV.GRANULE_ID = IV.GRANULE_ID, INVSENSOR
> INVS
has both an explicit and an implicit join. This can constrain join
re-ordering in the planner. Can you change it to explicit joins only
and see if
haven't tested a composite index
invsensor is 2,003,980 rows and 219MB
granver is 5,138,730 rows and 556MB
the machine has 32G memory
seq_page_cost, random_page_costs & effective_cache_size are set to the
defaults (1,4, and 128MB) - looks like they could be bumped up.
Got any recommendations?
thanks for taking a look at this and it's never too late!!
I've tried bumping up work_mem and did not see any improvements -
All the indexes do exist that you asked see below
Any other ideas?
CREATE INDEX invsnsr_idx1
ON invsensor
USING btree
(granule_id);
CREATE INDEX invsns
[ woops, accidentally replied off-list, trying again ]
On Tue, May 10, 2011 at 1:47 PM, Maria L. Wilson
wrote:
> thanks for taking a look at this and it's never too late!!
>
> I've tried bumping up work_mem and did not see any improvements -
> All the indexes do exist that you asked see
On Tue, Apr 5, 2011 at 3:25 PM, Maria L. Wilson
wrote:
> Would really appreciate someone taking a look at the query below Thanks
> in advance!
>
>
> this is on a linux box...
> Linux dsrvr201.larc.nasa.gov 2.6.18-164.9.1.el5 #1 SMP Wed Dec 9 03:27:37
> EST 2009 x86_64 x86_64 x86_64 GNU/Linux
yep - we use analyze and check the output. It's version 8.4.5 so no fsm
issues.
thanks, Maria
On 4/6/11 11:33 AM, Kevin Grittner wrote:
"Maria L. Wilson" wrote:
Autovacuum is not running - but regular vacuums are being done
twice daily.
Is the ANALYZE keyword used on those VACUUM runs?
Dne 6.4.2011 17:33, Kevin Grittner napsal(a):
> "Maria L. Wilson" wrote:
>
>> Autovacuum is not running - but regular vacuums are being done
>> twice daily.
>
> Is the ANALYZE keyword used on those VACUUM runs? What version of
> PostgreSQL is this. If it's enough to need fsm settings, do you
"Maria L. Wilson" wrote:
> Autovacuum is not running - but regular vacuums are being done
> twice daily.
Is the ANALYZE keyword used on those VACUUM runs? What version of
PostgreSQL is this. If it's enough to need fsm settings, do you run
with the VERBOSE option and check the end of the outp
thanks for the reply, Tomas. I'll test bumping up work_mem and see how
that helps.
thanks again, Maria Wilson
On 4/6/11 9:16 AM, t...@fuzzy.cz wrote:
some additional info.
the table inventory is about 4481 MB and also has postgis types.
the table gran_ver is about 523 MB
the table IN
Autovacuum is not running - but regular vacuums are being done twice daily.
indexes on inventory:
CREATE INDEX inven_idx1
ON inventory
USING btree
(inv_id);
CREATE UNIQUE INDEX inven_idx2
ON inventory
USING btree
(granule_id);
indexes on gran_ver:
CREATE UNIQUE INDEX granver_idx1
> some additional info.
> the table inventory is about 4481 MB and also has postgis types.
> the table gran_ver is about 523 MB
> the table INVSENSOR is about 217 MB
>
> the server itself has 32G RAM with the following set in the postgres conf
> shared_buffers = 3GB
> work_mem = 64MB
> maintena
On 5 April 2011 21:25, Maria L. Wilson wrote:
> Would really appreciate someone taking a look at the query below
> Thanks in advance!
>
>
> this is on a linux box...
> Linux dsrvr201.larc.nasa.gov 2.6.18-164.9.1.el5 #1 SMP Wed Dec 9 03:27:37
> EST 2009 x86_64 x86_64 x86_64 GNU/Linux
>
> expl
Would really appreciate someone taking a look at the query below
Thanks in advance!
this is on a linux box...
Linux dsrvr201.larc.nasa.gov 2.6.18-164.9.1.el5 #1 SMP Wed Dec 9
03:27:37 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
explain analyze
select MIN(IV.STRTDATE), MAX(IV.ENDDATE)
from G
15 matches
Mail list logo
