Re: [PERFORM] B-Heaps

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 p

Re: [PERFORM] B-Heaps

On Fri, Jun 18, 2010 at 1:53 PM, 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 th

Re: [PERFORM] B-Heaps

Kevin Grittner wrote: Yeb Havinga 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 i

Re: [PERFORM] B-Heaps

Greg Smith 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 suspect is a bottle

Re: [PERFORM] B-Heaps

Yeb Havinga 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 scanned. NB th

Re: [PERFORM] B-Heaps

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 probl

Re: [PERFORM] B-Heaps

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 actu

Re: [PERFORM] B-Heaps

On Fri, 18 Jun 2010, Robert Haas wrote: On Tue, Jun 15, 2010 at 8:23 AM, Matthew Wakeling 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 g

Re: [PERFORM] B-Heaps

On Tue, Jun 15, 2010 at 8:23 AM, Matthew Wakeling 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 simulate this to s

Re: [PERFORM] B-Heaps

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 http://www.cc.gatech.edu/~bader/COURSES/UNM/ece637-Fa

Re: [PERFORM] B-Heaps

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 a

Re: [PERFORM] B-Heaps

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:

Re: [PERFORM] B-Heaps

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 http://www.cc.gatech.edu/~bader/COURSES/UNM/ece637-Fall2003/papers/BFJ01

Re: [PERFORM] B-Heaps

On 15/06/10 06:21, Eliot Gable wrote: Just curious if this would apply to PostgreSQL: http://queue.acm.org/detail.cfm?id=1814327 Now that I've read it, it seems like a no-brainer. So, how does PostgreSQL deal with the different latencies involved in ac

[PERFORM] B-Heaps

Just curious if this would apply to PostgreSQL: http://queue.acm.org/detail.cfm?id=1814327 Now 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 / sort