rming
many random reads initially to fill the caches with random blocks. That
might allow for minimal assistance from the cache and be more realistic.
On Thu, May 30, 2013 at 11:13 AM, Merlin Moncure wrote:
> On Mon, May 27, 2013 at 9:02 AM, John Mudd wrote:
> > Postgres 9.1.2 on Ubunt
t (cost=0.00..8.36 rows=1
width=21) (actual time=21.070..21.072 rows=1 loops=1)
Index Cond: (id = 50)
Total runtime: 21.178 ms
On Mon, May 27, 2013 at 10:59 AM, Evgeny Shishkin wrote:
>
> On May 27, 2013, at 6:35 PM, John Mudd wrote:
>
> Thanks, that's easy e
test_select (cost=0.00..8.36 rows=1
width=21) (actual time=23.072..23.074 rows=1 loops=1)
Index Cond: (id = 50)
Total runtime: 23.192 ms
On Mon, May 27, 2013 at 10:21 AM, Evgeny Shishkin wrote:
>
> On May 27, 2013, at 6:02 PM, John Mudd wrote:
>
> > Postgres 9.1.2 on Ubu
Postgres 9.1.2 on Ubuntu 12.04
Any reason why a select by primary key would be slower than a select that
includes an ORDER BY? I was really hoping using the primary key would give
me a boost.
I stopped the server and cleared the O/S cache using "sync; echo 3 >
/proc/sys/vm/drop_caches" between th
