-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Adnan DURSUN
i want to be can read an execution plan when
i look at it.
So, is there any doc about how it should be read ?
You are asking how to read the output from EXPLAIN?
On Wed, 2006-10-04 at 07:38 -0500, Dave Dutcher wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Adnan DURSUN
i want to be can read an execution plan when
i look at it.
So, is there any doc about how it should be
On Tue, 2006-10-03 at 18:29 -0700, Tomeh, Husam wrote:
* When any session updates the data that already in shared
buffer,
does Postgres synchronize the data both disk and shared buffers area
immediately ?
Not necessarily true. When a block is modified in the shared buffers,
the
Hi,
I wonder how PostgreSQL caches the SQL query results. For example ;
* does postgres cache query result in memory that done by session A
?
* does session B use these results ?
Best Regards
Adnan DURSUN
---(end of
,
--
Husam
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Adnan
DURSUN
Sent: Tuesday, October 03, 2006 2:49 PM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] PostgreSQL Caching
Hi,
I wonder how PostgreSQL caches the SQL query results
an execution plan is created
before..
Sincenerly
Adnan DURSUN
- Original Message -
From: Tomeh, Husam [EMAIL PROTECTED]
To: Adnan DURSUN [EMAIL PROTECTED];
pgsql-performance@postgresql.org
Sent: Wednesday, October 04, 2006 1:11 AM
Subject: Re: [PERFORM] PostgreSQL Caching
Like many
: Re: [PERFORM] PostgreSQL Caching
Thanks,
I wonder these ;
* When any session updates the data that allready in shared
buffer,
does Postgres sychronize the data both disk and shared buffers area
immediately ?
* Does postgres cache SQL execution plan analyze
- Original Message -
From: Tomeh, Husam [EMAIL PROTECTED]
To: Adnan DURSUN [EMAIL PROTECTED];
pgsql-performance@postgresql.org
Sent: Wednesday, October 04, 2006 4:29 AM
Subject: RE: [PERFORM] PostgreSQL Caching
Query plans are not stored in the shared buffers and therefore can
Hello Josh,
JB Not that you can't improve the query, just that it might not fix
JB the problem.
Yes, I'm aware it might be slower than the Linux version, but then, as
you said, I still can improve the query (as I did with your help now).
But true, if there's something awfully wrong
On Tue, 2004-05-25 at 15:53, Vitaly Belman wrote:
QUERY PLAN
--
Limit (cost=2337.41..2337.43 rows=10 width=76) (actual
time=7875.000..7875.000 rows=10 loops=1)
- Sort (cost=2337.41..2337.94 rows=214 width=76) (actual
time=7875.000..7875.000 rows=10 loops=1)
Hello Marty, Nick and Robert,
NB Depending on what version of PG you are running, IN might take a while
NB to complete. If so try an EXISTS instead
RT A question and two experiments... what version of postgresql is this?
I am using the newer 7.5dev native Windows port. For this reason I
don't
Vitaly,
I am using the newer 7.5dev native Windows port. For this reason I
don't think that IN will cause any trouble (I read that this issue was
resolved in 7.4).
Well, for performance, all bets are off for the dev Windows port. Last I
checked, the Win32 team was still working on
Vitaly Belman wrote:
If you'll be so kind though, I'd be glad if you could spot anything to
speed up in this query. Here's the query and its plan that happens
without any caching:
-
QUERY
Hello Jochem and Marty,
I guess I should have posted the table structure before =(:
Table structure + Indexes
-
CREATE TABLE public.bv_books
(
book_id serial NOT NULL,
book_title varchar(255) NOT NULL,
series_id int4,
series_index int2,
annotation_desc_id int4,
Vitaly,
This looks like there might be some room for performance improvement...
MS I didn't see the table structure, but I assume
MS that the vote_avg and
MS vote_count fields are in bv_bookgenres.
I didn't understand you. vote_avg is stored in bv_books.
Ok. That helps. The confusion (on my
Hello Marty,
MS Is that a composite index?
It is a regular btree index. What is a composite index?
My apologies. A composite index is one that consists of multiple fields
(aka multicolumn index). The reason I ask is that it was spending
almost half the time just searching bv_bookgenres,
Hello Marty,
MS Is that a composite index?
It is a regular btree index. What is a composite index?
MS Analyzing the taables may help, as the optimizer appears to
MS mispredict the number of rows returned.
I'll try analyzing, but I highly doubt that it would help. I analyzed
once already and
Hello,
I have the following problem:
When I run some query after I just run the Postmaster, it takse
several seconds to execute (sometimes more than 10), if I rerun it
again afterwards, it takes mere milliseconds.
So, I guess it has to do with PostgreSQL caching.. But how exactly
does it work?
while you weren't looking, Vitaly Belman wrote:
So, I guess it has to do with PostgreSQL caching.. But how exactly
does it work? What does it cache? And how can I control it?
PostgreSQL uses the operating system's disk cache. You can hint to
the postmaster how much memory is available for
Vitaly Belman wrote:
Hello,
I have the following problem:
When I run some query after I just run the Postmaster, it takse
several seconds to execute (sometimes more than 10), if I rerun it
again afterwards, it takes mere milliseconds.
So, I guess it has to do with PostgreSQL caching.. But how
[EMAIL PROTECTED] (Richard Huxton) writes:
If you could pin data in the cache it would run quicker, but at the
cost of everything else running slower.
Suggested steps:
1. Read the configuration/tuning guide at:
http://www.varlena.com/varlena/GeneralBits/Tidbits/index.php
2. Post a sample
What is essentially required is the prescient cacheing algorithm,
where the postmaster must consult /dev/esp in order to get a
prediction of what blocks it may need to refer to in the next sixty
seconds.
Easy enough. Television does it all the time with live shows. The guy
with the buzzer
Rosser Schwarz wrote:
PostgreSQL uses the operating system's disk cache.
... in addition to its own buffer cache, which is stored in shared
memory. You're correct though, in that the best practice is to keep the
PostgreSQL cache small and give more memory to the operating system's
disk cache.
Not knowing a whole lot about the internals of Pg, one thing jumped out
at me, that each trip to get data from bv_books took 2.137 ms, which
came to over 4.2 seconds right there.
The problem seems to be the 1993 times that the nested loop spins, as
almost all of the time is spent there.
24 matches
Mail list logo
