We are hoping the spec will get wrapped up in the next 6 months, but industry
standard councils move very slowly! However, if there is interest in getting
involved and helping, the TPC might be receptive to earlier access.
BTW, just to let folks know how large of an undertaking this has been, t
On 07/23/2014 06:18 PM, Reza Taheri wrote:
> [By way of introduction, we are a TPC subcommittee that is developing a
> benchmark with cloud-like characteristics for virtualized databases. The
> end-to-end benchmarking kit will be publicly available, and will run on
> PGSQL]
Awesome! Any idea when
On 25/07/2014 2:58 PM, Reza Taheri wrote:
Hi Craig,
According to the attached SQL, each frame is a separate phase in the operation
and performs many different operations.
There's a *lot* going on here, so identifying possible interdependencies isn't
something I can do in a ten minute skim
rea
Hi Craig,
> According to the attached SQL, each frame is a separate phase in the
> operation and performs many different operations.
> There's a *lot* going on here, so identifying possible interdependencies
> isn't something I can do in a ten minute skim
> read over my morning coffee.
You didn
?? 2014/7/25 9:53, Tom Lane :
[ shrug... ] Insufficient data. When I try a simple test case based on
what you've told us, I get planning times of a couple of milliseconds.
I can think of contributing factors that would increase that, but not
by four orders of magnitude. So there's something
On 07/24/2014 10:22 PM, Borodin Vladimir wrote:
> Hi all.
>
> I have a database with quiet heavy writing load (about 20k tps, 5k of
> which do writes). And I see lots of writing I/O (I mean amount of data,
> not iops) to this database, much more than I expect. My question is how
> can I debug what
