Robert Haas wrote:
This is drifting a bit off-topic for this thread, but it's not so easy
to figure out from looking at the TODO which things are actually
important. Performance-related improvements are mixed in with
non-performance related improvements, which are mixed in with things
that are
On Fri, Jun 18, 2010 at 1:53 PM, Greg Smith g...@2ndquadrant.com wrote:
Matthew Wakeling wrote:
This sort of thing has been fairly well researched at an academic level,
but has not been implemented in that many real world situations. I would
encourage its use in Postgres.
I guess, but don't
On Tue, Jun 15, 2010 at 8:23 AM, Matthew Wakeling matt...@flymine.org wrote:
Absolutely, and I said in
http://archives.postgresql.org/pgsql-performance/2010-03/msg00272.php
but applied to the Postgres B-tree indexes instead of heaps.
This is an interesting idea. I would guess that you could
On Fri, 18 Jun 2010, Robert Haas wrote:
On Tue, Jun 15, 2010 at 8:23 AM, Matthew Wakeling matt...@flymine.org wrote:
Absolutely, and I said in
http://archives.postgresql.org/pgsql-performance/2010-03/msg00272.php
but applied to the Postgres B-tree indexes instead of heaps.
This is an
Matthew Wakeling wrote:
This sort of thing has been fairly well researched at an academic
level, but has not been implemented in that many real world
situations. I would encourage its use in Postgres.
I guess, but don't forget that work on PostgreSQL is driven by what
problems people are
Greg Smith wrote:
Matthew Wakeling wrote:
This sort of thing has been fairly well researched at an academic
level, but has not been implemented in that many real world
situations. I would encourage its use in Postgres.
I guess, but don't forget that work on PostgreSQL is driven by what
Yeb Havinga yebhavi...@gmail.com wrote:
concerning gist indexes:
1) with larger block sizes and hence, larger # entries per gist
page, results in more generic keys of those pages. This in turn
results in a greater number of hits, when the index is queried, so
a larger part of the index is
Greg Smith g...@2ndquadrant.com writes:
Your characterization of the potential speed up here is Using a proper tree
inside the index page would improve the CPU usage of the index lookups,
which seems quite reasonable. Regardless, when I consider is that
something I have any reason to
Kevin Grittner wrote:
Yeb Havinga yebhavi...@gmail.com wrote:
concerning gist indexes:
1) with larger block sizes and hence, larger # entries per gist
page, results in more generic keys of those pages. This in turn
results in a greater number of hits, when the index is queried, so
a
In response to Greg Smith :
For details about what the database does there, see Inside the
PostgreSQL Buffer Cache at http://projects.2ndquadrant.com/talks
Nice paper, btw., thanks for that!
Regards, Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -
On Mon, 14 Jun 2010, Eliot Gable wrote:
Just curious if this would apply to PostgreSQL:
http://queue.acm.org/detail.cfm?id=1814327
Absolutely, and I said in
http://archives.postgresql.org/pgsql-performance/2010-03/msg00272.php
but applied to the Postgres B-tree indexes instead of heaps. It's
Greg Smith wrote:
Eliot Gable wrote:
Just curious if this would apply to PostgreSQL:
http://queue.acm.org/detail.cfm?id=1814327
It's hard to take this seriously at all when it's so ignorant of
actual research in this area. Take a look at
Just curious if this would apply to PostgreSQL:
http://queue.acm.org/detail.cfm?id=1814327
http://queue.acm.org/detail.cfm?id=1814327Now that I've read it, it seems
like a no-brainer. So, how does PostgreSQL deal with the different latencies
involved in accessing data on disk for searches / sorts
13 matches
Mail list logo
