On Fri, Jul 22, 2011 at 5:15 PM, Greg Smith g...@2ndquadrant.com wrote:
That looks straightforward enough.
OK, committed.
The other thing I keep realizing would
be useful recently is to allow specifying a different tablespace to switch
to when creating all of the indexes. The old data here,
On 07/25/2011 09:23 AM, Robert Haas wrote:
At some point, we also need to sort out the scale factor limit issues,
so you can make these things bigger.
I had a patch to improve that whole situation, but it hasn't seem to nag
at me recently. I forget why it seemed less important, but I
On Fri, Jul 22, 2011 at 10:15:08PM -0400, Greg Smith wrote:
On 07/22/2011 08:15 PM, David Fetter wrote:
Do you have any theories as to how indexing on SSD speeds things
up? IIRC you found only marginal benefit in putting WALs there.
Are there cases that SSD helps more than others when it
I know I'm not the only one to hack up pgbench to create unlogged
tables, so I thought maybe it would be useful to have an option to do
that.
I wasn't excited about picking a single letter option name, so I
modified pgbench to use getopt_long. Patch attached.
--
Robert Haas
EnterpriseDB:
That looks straightforward enough. The other thing I keep realizing
would be useful recently is to allow specifying a different tablespace
to switch to when creating all of the indexes. The old data here,
indexes on faster storage here trick was already popular in some
environments. But
On Fri, Jul 22, 2011 at 05:15:37PM -0400, Greg Smith wrote:
That looks straightforward enough. The other thing I keep realizing
would be useful recently is to allow specifying a different
tablespace to switch to when creating all of the indexes. The old
data here, indexes on faster storage
On 07/22/2011 08:15 PM, David Fetter wrote:
Do you have any theories as to how indexing on SSD speeds things up?
IIRC you found only marginal benefit in putting WALs there. Are there
cases that SSD helps more than others when it comes to indexing?
Yes, I've found a variety of workloads
