Tobias Brox wrote:
I think those pages probably should be merged ... hmm ... if
I manage to solve my locking issues I should probably try and
contribute to the wiki.
Certainly the 3rd one could be merged with one of the other two, and
maybe all merged into one. I haven't cleaned up that wh
On Wed, Sep 15, 2010 at 2:26 AM, Anssi Kääriäinen
wrote:
> Hello all,
>
> I am trying to use aggregate queries in views, and when joining these views
> to other
> tables, I get seq scan in the view, even if index scan would be clearly
> better. The views
> I am using in my Db are actually long piv
On 15 September 2010 21:28, Greg Smith wrote:
> There are some useful examples of lock views on the wiki:
>
> http://wiki.postgresql.org/wiki/Lock_Monitoring
> http://wiki.postgresql.org/wiki/Lock_dependency_information
> http://wiki.postgresql.org/wiki/Find_Locks
Thanks. I think those pages pro
On Thu, Aug 26, 2010 at 6:32 AM, Willy-Bas Loos wrote:
> I have a colleague that is convinced that the website is faster if
> enable_seqscan is turned OFF.
> I'm convinced of the opposite (better to leave it ON), but i would like to
> show it, prove it to him.
> Now the first query we tried, would
On 10-09-15 03:07 PM, Tobias Brox wrote:
On 15 September 2010 15:39, Tom Lane wrote:
An exclusive lock will block selects too. Have you looked into pg_locks
for ungranted lock requests?
Well - I thought so, we have a logging script that logs the content of
the pg_locks table, it didn't log a
Tobias Brox wrote:
I thought so, we have a logging script that logs the content of
the pg_locks table, it didn't log anything interesting but it may be a
problem with the script itself. It does an inner join on
pg_locks.relation = pg_class.oid but when I check now this join seems
to remove most
Tobias Brox writes:
> Well - I thought so, we have a logging script that logs the content of
> the pg_locks table, it didn't log anything interesting but it may be a
> problem with the script itself. It does an inner join on
> pg_locks.relation = pg_class.oid but when I check now this join seems
On 15 September 2010 15:39, Tom Lane wrote:
> An exclusive lock will block selects too. Have you looked into pg_locks
> for ungranted lock requests?
Well - I thought so, we have a logging script that logs the content of
the pg_locks table, it didn't log anything interesting but it may be a
probl
Hello all,
I am trying to use aggregate queries in views, and when joining these
views to other
tables, I get seq scan in the view, even if index scan would be clearly
better. The views
I am using in my Db are actually long pivot queries, but the following
simple test case is enough
to show t
Thanks all for your help. I didn't really understand why it was sorting on
every field, but it now makes sense. What I ended up doing was replacing
the
SELECT DISTINCT * FROM JOIN ... WHERE ... ORDER BY... LIMIT ...
with
SELECT * FROM ... WHERE id in (SELECT DISTINCT id FROM JOIN ...
On Wed, 15 Sep 2010, Merlin Moncure wrote:
On Wed, Sep 15, 2010 at 2:32 AM, Gerhard Wiesinger wrote:
On Tue, 14 Sep 2010, Merlin Moncure wrote:
np -- this felt particularly satisfying for some reason. btw, I think
you have some more low hanging optimization fruit. I think (although
it would
Tobias Brox writes:
> Recently we've frequently encountered issues where some simple selects
> (meaning, selects doing an index lookup and fetching one row) have
> become stuck for several minutes. Apparently all requests on one
> exact table gets stuck, all requests not related to said table are
wrote:
> I am running into a POSTGRES error. It appears to be the
> DBMGR[4289]. Any ideas what the error maybe?
I've never seen anything remotely like that. I don't see the string
'DBMGR' anywhere in the PostgreSQL source.
Before anyone can begin to help you, we would need a lot more
infor
On Wed, Sep 15, 2010 at 2:32 AM, Gerhard Wiesinger wrote:
> On Tue, 14 Sep 2010, Merlin Moncure wrote:
>>
>> np -- this felt particularly satisfying for some reason. btw, I think
>> you have some more low hanging optimization fruit. I think (although
>> it would certainly have to be tested) hidin
Sorry for the blast...
I am running into a POSTGRES error. It appears to be the DBMGR[4289]. Any ideas
what the error maybe?
[cid:image001.png@01CB549C.48946FF0]
<>
We have a production database server ... it's quite busy but usually
working completely fine, simple queries taking a fraction of a
millisecond to run.
Recently we've frequently encountered issues where some simple selects
(meaning, selects doing an index lookup and fetching one row) have
become s
16 matches
Mail list logo
