From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Kevin Grittner <kgrittn(at)ymail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reduce pinning in btree indexes |
Date: | 2015-03-18 03:01:16 |
Message-ID: | 5508EA7C.9090501@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/16/15 11:47 AM, Robert Haas wrote:
> I am sure there are more sophisticated things to be done here, but I
> guess my feeling is that time is a good way to go here for a first cut
> - lots of people have suggested it, and there's clearly a use case for
> it. If the setting turns out to be popular, we can fine-tune it more
> once we've got some experience with it. But I'm nervous about trying
> to to design something more complicated than that right now,
> especially so late in the release cycle. We know that this setting,
> with time-based units, will meet the needs of the customer for whom it
> was developed, and that is a good-enough reason to think that time is
> a reasonable metric for this, even if we eventually have others.
+1. As you said, time is easy for people to understand, and I think it
will handle a large chunk of the use cases.
I used to have this quote (or something close to it) on my whiteboard...
I think it's appropriate here ;)
"The perfect is the enemy of the good. -Simon Riggs"
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2015-03-18 03:06:44 | Re: xloginsert.c hole_length warning on gcc 4.8.3 |
Previous Message | Jim Nasby | 2015-03-18 02:45:02 | Re: proposal: searching in array function - array_position |