get better
performance by allocating most of the memory to the buffer cache rather
than leaving it to the kernel file cache.
I'm actually fairly curious to see what the new buffer management scheme
will mean in terms of real world performance and parameter tuning.
-James Rogers
I've gotten the green light (and many responses from people interested
in doing it) to start writing up RFQs for specific features, which I
will post to the pg-hackers list. It is all stuff previously determined
to be doable within the current PostgreSQL framework, and just requiring
some work that
for going about doing
this?
Cheers,
-James Rogers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
If you think they are orthogonal, you don't understand the
nature of this particular beast.
Cheers,
-James Rogers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
On 10/14/03 11:31 PM, "James Rogers" <[EMAIL PROTECTED]> wrote:
>
> There is some abstraction in Postgres and the database is well-written, but
> it isn't written in a manner that makes it easy to swap out operating system
> or API models. It is written to be po
a set of operating system APIs
is never going to give stellar or even results across all platforms because
the operating system APIs usually aren't written so that you could write
your database optimally.
Theoretically, it is the difference between middling performance in the
typical case and
s move to a database kernel eventually for a lot
of reasons, but it would a relatively significant change. Maybe v8? :-)
Cheers,
-James Rogers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
o I guess I have two questions:
1) Does anyone object to me working on these two areas?
2) What version target should I realistically be shooting for?
Cheers,
-James Rogers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 7: don't forget to
need to understand the
limitations, nonetheless when tables and databases get really big it becomes
an important tool in the tool belt.
Cheers,
-James Rogers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 8: explain analyze is your friend
On 10/2/03 11:34 PM, "Hannu Krosing" <[EMAIL PROTECTED]> wrote:
> James Rogers kirjutas N, 02.10.2003 kell 23:44:
>> Not exactly. What you are describing is more akin to partitioning or
>> hash-organized tables i.e. sorting insert/update tuples to various pages
>
R index doesn't tell you much about which
pages would currently be a good place to put a new tuple. You could
always markup the index that CLUSTER uses to keep track of good
candidates (plus some additional structures), but the more I think about
that, the more it looks like a nasty hack
number of relevant tuples per buffer is low for a given query, so we
aren't getting much tuple bang for the buffer buck. I suppose one could
look at it as trying to improve the intra-buffer hit rate for a given
query.
Cheers,
-James Rogers
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 8: explain analyze is your friend
lassic scenario for this is when you have a large collection of
time-series data stored in a table, with each series keyed to another
table. The the typical tuple distribution creates pathological
behaviors when buffer space becomes tight.
Cheers,
-James Rogers
[EMAIL PROTECTED]
ng this type of feature (automatic
table layout optimization), but I thought I would check with the people
currently hacking on the system first, to see if there was a showstopper or
if someone is already working on this.
Cheers,
-James Rogers
[EMAIL PROTECTED]
---(end of b
14 matches
Mail list logo
