Jan wrote:
> > The disk cache on most operating systems is optimized. Plus,
keeping
> > shared buffers low gives you more room to bump up the sort memory,
which
> > will make your big queries run faster.
>
> Plus, the situation will change dramatically with 7.5 where the disk
> cache will have le
Andy wrote:
> Whether the OS caches the data or PG does, you still want it cached.
If
> your
> sorting backends gobble up the pages that otherwise would be filled
with
> the
> database buffers, then your postmaster will crawl, as it'll *really*
have
> to
> wait for stuff from disk. In my scenario,
> What would be most interesting to see is whether this makes it wise to
> increase shared buffer size. It may be more effective to bump down
> the cache a little, and bump up sort memory; hard to tell.
How do we go about scheduling tests with the OSDL folks? If they could
do 10 runs with buffers
Rond, Chris,
> > What would be most interesting to see is whether this makes it wise to
> > increase shared buffer size. It may be more effective to bump down
> > the cache a little, and bump up sort memory; hard to tell.
>
> How do we go about scheduling tests with the OSDL folks? If they could
On 7/12/2004 12:38 PM, Josh Berkus wrote:
Rond, Chris,
> What would be most interesting to see is whether this makes it wise to
> increase shared buffer size. It may be more effective to bump down
> the cache a little, and bump up sort memory; hard to tell.
How do we go about scheduling tests with
> "alix" == alix <[EMAIL PROTECTED]> writes:
alix> Le Mon, 12 Jul 2004 12:37:47 +0200 (CEST) Jean-Luc Ancey
alix> <[EMAIL PROTECTED]> & stef écrivit:
>> > Pour moi la même chose que l'année dernière : on > s'abstient.
alix> Pour moi la même chose que l'année dernière : on y va.
Ide
>
> Considering you're pulling out 450k rows in 8 seconds, I'd also guess
> the data is mostly in memory. Is that normal? Or is this a result of
> having run several test queries against the same data multiple times?
>
Ah yes, that would have been the result of running the query several
times...
> Oddly enough, I put the same database on a different machine, and the
> query now behaves as I hoped all along. Notice that I'm using the
> "real" query, with the aspid in asc and the other fields in desc order,
> yet the query does use the call_idx13 index:
Notice that while it only takes 19 s
Hi all,
I'm storing some timestamps as integers (UTF) in a table and I want to
query by <= and >= for times between a certain period. The table has
gotten quite large and is now very slow in querying.
I think it's time to create an index for the timestamp column.
I tried using an rtree (for <=
Chris Cheston <[EMAIL PROTECTED]> writes:
> I'm storing some timestamps as integers (UTF) in a table and I want to
> query by <= and >= for times between a certain period.
btree can handle range queries nicely; why do you think you need an
rtree? rtree is for 2-dimensional datums which a timestam
I'm storing some timestamps as integers (UTF) in a table and I want to
query by <= and >= for times between a certain period. The table has
gotten quite large and is now very slow in querying.
I think it's time to create an index for the timestamp column.
Uh, yeah.
I tried using an rtree (for <= a
11 matches
Mail list logo
