On Wed, 5 Aug 2009, Greg Stark wrote:
On Tue, Aug 4, 2009 at 11:56 PM, Robert Haas wrote:
Beats me. It looks like the first few queries are pulling stuff into
cache, and then after that it settles down, but I'm not sure why it
takes 5 repetitions to do that. Is the plan changing?
Yeah, we're
Kees van Dieren wrote:
> Hi Folks,
>
> Thanks for your response.
>
> I have added the following index (suggested by other post):
>
> CREATE INDEX events_events_cleared_eventtype
> ON events_events
> USING btree
> (eventtype_id, cleared)
> WHERE cleared = false;
>
> Also with columns in reve
On Wed, Aug 5, 2009 at 6:20 AM, Matthew Wakeling wrote:
> It is certainly doing a sequential scan. So are you saying that it will
> start a sequential scan from a different part of the table each time, even
> in the absence of other simultaneous sequential scans? Looks like I'm going
> to have to r
On Wed, 5 Aug 2009, Robert Haas wrote:
On Wed, Aug 5, 2009 at 6:20 AM, Matthew Wakeling wrote:
It is certainly doing a sequential scan. So are you saying that it will
start a sequential scan from a different part of the table each time, even
in the absence of other simultaneous sequential scans?
Matthew Wakeling writes:
> It is certainly doing a sequential scan. So are you saying that it will
> start a sequential scan from a different part of the table each time, even
> in the absence of other simultaneous sequential scans?
Yeah, that's the syncscan logic biting you. You can turn it o
On Tue, Aug 4, 2009 at 4:40 PM, Tom Lane wrote:
> Scott Carey writes:
>> There are a handful of other compression algorithms very similar to LZO in
>> performance / compression level under various licenses.
>> LZO is just the best known and most widely used.
>
> And after we get done with the lice
On 8/5/09 7:12 AM, "Merlin Moncure" wrote:
> On Tue, Aug 4, 2009 at 4:40 PM, Tom Lane wrote:
>> Scott Carey writes:
>>> There are a handful of other compression algorithms very similar to LZO in
>>> performance / compression level under various licenses.
>>> LZO is just the best known and mos
We have found the problem. Apparently there was a query doing count on
45 million rows table run prior to the episode of slow query. Definitely
cached data is pushed out the memory. Is there way to assign portion of
memory to recycling purposes like in oracle, so the cached data doesn't
get affecte
On 8/5/09 12:16 PM, "Subbiah Stalin-XCGF84" wrote:
> We have found the problem. Apparently there was a query doing count on
> 45 million rows table run prior to the episode of slow query. Definitely
> cached data is pushed out the memory. Is there way to assign portion of
> memory to recycling
"Subbiah Stalin-XCGF84" wrote:
> We have found the problem.
Great news!
> Apparently there was a query doing count on 45 million rows table
> run prior to the episode of slow query. Definitely cached data is
> pushed out the memory.
Yeah, that would completely explain your symptoms.
> I
I have a database (699221). It contains of 1.8GB data (707710). I am
doing a complex query. Which required to load a 80MB index (732287).
I restarted Postgresql so the cache is empty and it has to read the
table and index from disk. Which I understand is an expensive process.
But what I don't unde
On Wed, Aug 5, 2009 at 8:50 PM, Ip Wing Kin John wrote:
> I have a database (699221). It contains of 1.8GB data (707710). I am
> doing a complex query. Which required to load a 80MB index (732287).
>
> I restarted Postgresql so the cache is empty and it has to read the
> table and index from disk.
Hi Scott,
Yes I did that. And you are right because I restart my machine, so the
postgres cache is empty. And I think postgresql is reading all 1.8GB of
data back into the cache when it does a seq scan on the status table.
QUERY PLAN
-
Could you possibly attach that in plain text format? Your email
client seems to have eaten any text formatting / indentation.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Is this alright?
QUERY PLAN
---
Sort (cost=390162.53..390162.54 rows=3 width=567) (actual
time=106045.453..106 0
Sorry post again.
QUERY PLAN
---
Sort (cost=390162.53..390162.54 rows=3 width=567) (actual
time=105726.803..105 7
On Wed, Aug 5, 2009 at 11:21 PM, wrote:
> Sorry post again.
Nope, still mangled. Can you attach it?
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Hi scott
I attached the query plan with this email. The top one is the first
run after I restarted my machine. And the bottom one is the second
run.
I am using PostgreSQL 8.3 on Solaris 10.
cheers
On Thu, Aug 6, 2009 at 4:15 PM, Scott Marlowe wrote:
> On Wed, Aug 5, 2009 at 11:21 PM, wrote:
>>
18 matches
Mail list logo
