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 buff
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
> -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
- Original Message -
From: "Tomeh, Husam" <[EMAIL PROTECTED]>
To: "Adnan DURSUN" <[EMAIL PROTECTED]>;
Sent: Wednesday, October 04, 2006 4:29 AM
Subject: RE: [PERFORM] PostgreSQL Caching
Query plans are not stored in the shared buffers and there
Adnan
DURSUN
Sent: Tuesday, October 03, 2006 4:53 PM
To: pgsql-performance@postgresql.org
Subject: 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 di
Because an execution plan is created
before..
Sincenerly
Adnan DURSUN
- Original Message -
From: "Tomeh, Husam" <[EMAIL PROTECTED]>
To: "Adnan DURSUN" <[EMAIL PROTECTED]>;
Sent: Wednesday, October 04, 2006 1:11 AM
Subject: Re: [PERFORM] PostgreSQL Cach
,
--
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
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 broadcast)
>
> 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 awfu
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 with Win32
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 *stabi
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
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
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
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 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 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_bookgenr
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
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.
Pers
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.
P
> 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 buzze
[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
Hello Richard and Rosser,
Thank you both for the answers.
I tried creating a semi cache by running all the queries and indeed it
worked and I might use such way in the future if needed, yet though, I
can't help but to feel it isn't exactly the right way to work around
this problem. If I do, I mig
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 exact
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 ca
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? W
26 matches
Mail list logo
