charavay <[EMAIL PROTECTED]> writes:
> ... So the planner decides to scan 33 000 000 of tuples and we would like to
> force it to scan the table dic (303 000 tuples) and to use
> the index on the integer index to execute the join.
I'm mystified why you think that that will be a superior plan. It
Trying to think a little out of the box, how "common" is it in modern
operating systems to be able to swap out shared memory?
Maybe we're not using the ARC algorithm correctly after all. The ARC
algorithm does not consider the second level OS buffer cache in it's
design. Maybe the total size of
Jan Wieck <[EMAIL PROTECTED]> writes:
> I realized that StrategyDirtyBufferList currently wasts a lot of time by
> first scanning over all the buffers that haven't even been hit since
> it's last call and neither have been dirty last time (and thus, are at
> the beginning of the list and can't b
Simon,
> I agree that you could test this by running on a bigger or smaller server,
> i.e. one with more or less RAM. Running on a faster/slower server at the
> same time might alter the results and confuse the situation.
Unfortunately, a faster server is the only option I have that also has more
On 10/17/2004 3:40 PM, [EMAIL PROTECTED] wrote:
Seeing as I've missed the last N messages... I'll just reply to this
one, rather than each of them in turn...
Tom Lane <[EMAIL PROTECTED]> wrote on 16.10.2004, 18:54:17:
I wrote:
> Josh Berkus writes:
>> First off, two test runs with OProfile are ava
Charavay,
> ---
> Hash Join (cost=6793.29..1716853.80 rows=33743101 width=11)
> Hash Cond: ("outer"."index" = "inner"."index")
> -> Seq Scan on lnk (cost=0.00..535920.00 rows=33743100 width=15)
> -> Hash
On 10/14/2004 8:10 PM, Christopher Browne wrote:
Quoth [EMAIL PROTECTED] ("Simon Riggs"):
I say this: ARC in 8.0 PostgreSQL allows us to sensibly allocate as
large a shared_buffers cache as is required by the database
workload, and this should not be constrained to a small percentage
of server RAM.
On 10/14/2004 6:36 PM, Simon Riggs wrote:
[...]
I think Jan has said this also in far fewer words, but I'll leave that to
Jan to agree/disagree...
I do agree. The total DB size has as little to do with the optimum
shared buffer cache size as the total available RAM of the machine.
After reading y
On 10/13/2004 11:47 PM, Bruce Momjian wrote:
Josh Berkus wrote:
Aaron,
> That makes two of us. Hanging out with Tom, Bruce, and others at OSCON
> 2002 was one of the most informative and fun times I've had. That and
> I could really stand to brush up on my Postgres basics
You're thinking of Jan.
[EMAIL PROTECTED] wrote:
Hello
I posted this on the general list but think it would be more appropriate
here. Sorry.
I know it is possible to time isolated queries through the settting of the
\timing option in psql. This makes PgSQL report the time it took to
perform one operation.
I would like to
Hello
I posted this on the general list but think it would be more appropriate
here. Sorry.
I know it is possible to time isolated queries through the settting of the
\timing option in psql. This makes PgSQL report the time it took to
perform one operation.
I would like to know how one can get a
Hi,
I have a problem
where a query inside a function is up to 100 times slower inside a function than
as a stand alone query run in psql.
The column
'botnumber' is a character(10), is indexed and there are 125000 rows in the
table.
Help
please!
This query is
fast:-
explain
analy
On Fri, Oct 15, 2004 at 09:22:03PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Mark Wong <[EMAIL PROTECTED]> writes:
> > > I know where the do_sigaction is coming from in this particular case.
> > > Manfred Spraul tracked it to a pair of pgsignal calls in libpq.
> > > Commenting out those two
Hello !
We have difficulties with the use of indexes. For example, we have two
tables :
* table lnk :
Table "public.lnk"
Column | Type | Modifiers
+---+---
index | integer | not null
sgaccn | character varying(12) | not
14 matches
Mail list logo
