David Brown <[EMAIL PROTECTED]> writes:
> The planner is not breaking up the outer join in his v_packages view:
The planner doesn't make any attempt to rearrange join order of outer
joins. There are some cases where such a rearrangement is OK, but there
are other cases where it isn't, and we don'
After a long battle with technology, Gaetano Mendola <[EMAIL PROTECTED]>, an
earthling, wrote:
> JM wrote:
>> Hi ALL,
>>
>> I was wondering if there is a DB performance reduction if
>> there are a lot of IDLE processes.
>>
>> 30786 ?S 0:00 postgres: user1 gmadb 10.10.10.1 idle
Tom Lane wrote:
However: the reason the second plan wins is because there are zero rows
fetched from sat_request, and so the bulk of the plan is never executed
at all. I doubt the second plan would win if there were any matching
sat_request rows.
That's what I thought at first, but if you look mor
Klint Gore <[EMAIL PROTECTED]> writes:
> Is having an order by in a view legal?
Not according to the SQL spec, but PG has allowed it for several releases.
(The same goes for ORDER BY in a sub-select, which is actually pretty
much the same thing ...)
> If so, does it do 2 sorts when you sort by so
> I would suspect a DBI/DBD installation issue, either perl DBI cannot
> find DBD-Pg (not installed ?) or DBD-Pg cannot find your Pg 7.4.5.
>
> I note that FC3 comes with Pg 7.4.6 - did you installed 7.4.5 from
> source? If so this could be why the perl database modules cannot find it
> (you may ne
On Sun, 20 Feb 2005 13:46:10 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
> sat_request rows. If this is the case you actually need to optimize,
> probably the thing to do is to get rid of the ORDER BY clauses you
> evidently have in your views, so that there's some chance of building
> a fast-start
JM wrote:
> Hi ALL,
>
> I was wondering if there is a DB performance reduction if there are a
> lot of
> IDLE processes.
>
> 30786 ?S 0:00 postgres: user1 gmadb 10.10.10.1 idle
> 32504 ?S 0:00 postgres: user1 gmadb 10.10.10.1 idle
> 32596 ?S 0:00 pos
Tom Lane wrote:
> Gaetano Mendola <[EMAIL PROTECTED]> writes:
>
>>If you need other info in order to improve the planner,
>
>
> ... like, say, the PG version you are using, or the definitions of the
> views involved? It's difficult to say much of anything about this.
That is true, sorry I forgot
[EMAIL PROTECTED] wrote:
I newly installed the postgresql 7.4.5 and FC 3 in my server and transfer the
data from 7.3.2 with just a few problems. After I use the webmin 1.8 to config
the grant previllage to the users ,I found that there is an error in the grant
previlege .
postgresql --> Grant Previ
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> If you need other info in order to improve the planner,
... like, say, the PG version you are using, or the definitions of the
views involved? It's difficult to say much of anything about this.
However: the reason the second plan wins is because ther
>> I don't think that's correct either. Scatter/Gather I/O is
>used to SQL
>> Server can issue reads for several blocks from disks into it's own
>> buffer cache with a single syscall even if these buffers are not
>> sequential. It did make significant performance improvements
>when they
>> added
I newly installed the postgresql 7.4.5 and FC 3 in my server and transfer the
data from 7.3.2 with just a few problems. After I use the webmin 1.8 to config
the grant previllage to the users ,I found that there is an error in the grant
previlege .
postgresql --> Grant Previlege --> error
select re
Hi all,
I'm stuck in a select that use the hash join where should not:
6 seconds vs 0.3 ms !!
If you need other info in order to improve the planner,
let me know.
Regards
Gaetano Mendola
empdb=# explain analyze SELECT id_sat_request
empdb-#FROM sat_request sr,
empdb-# v_sc_package
Hi all,
I Got more improvements using vacuumdb utility and the size of my database
was decreasead from 1.3gb to 900mb.
Only one thing is not right yeat. My procedure perform others 7
subprocedures and with reimported database, it's took about 5 minutes to
complete. With old vacuumed database, the
14 matches
Mail list logo
