Bruce Momjian br...@momjian.us writes:
Greg Stark wrote:
Putting aside the politics questions, count(*) is an interesting case
-- it exposes some of the unanswered questions about index-only scans.
The reason select count(*) might win would be because we could pick
any index and do an index
It seems to me a reasonable way to implement VARIANT would be to have
a data type called VARIANT that stores an OID of the inner type at the
beginning, followed by the binary data. When you say
pg_typeof(somevariant), you'll get 'variant'. Instead, you'd use a
function like this:
On Tue, May 10, 2011 at 10:29 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
The VARIANT type, or similar, would be useful for the JSON data type
I've been intermittently working on, as it would allow us to create a
function like this:
from_json(JSON) returns VARIANT
This occurred to
2011/5/11 Joseph Adams joeyadams3.14...@gmail.com:
On Tue, May 10, 2011 at 10:29 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
The VARIANT type, or similar, would be useful for the JSON data type
I've been intermittently working on, as it would allow us to create a
function like this:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Greg Stark wrote:
Putting aside the politics questions, count(*) is an interesting case
-- it exposes some of the unanswered questions about index-only scans.
The reason select count(*) might win would be because we could pick
On Wed, 06 Apr 2011 22:07:52 +0200, Brar Piening b...@gmx.de wrote:
On Wed, 06 Apr 2011 20:04:37 +0200, Brar Piening b...@gmx.de wrote:
It's not ready yet but I'm prepared to get back to it as soon as
there's some serious interest.
I've updated the patch once again to reflect the fixes to
On Wed, 11 May 2011 06:15:08 +0200, Brar Piening b...@gmx.de wrote:
I've updated the patch once again to reflect the fixes to pgbison.bat
in my alternative pgbison.pl
Actually not pgbison but pgflex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
The name of this new option is a bit of a mouthful, and it mixes in an
otherwise standardized term (deferrable, as in constraints) with
transaction isolation. Wouldn't something like --wait-for-serializable
be clearer (and shorter)?
--
Sent via pgsql-hackers mailing list
On tis, 2011-05-10 at 22:20 -0400, Tom Lane wrote:
My conclusion about all this is that we really need to invent another
GucSource value falling between PGC_S_DEFAULT and PGC_S_ENV_VAR,
called perhaps PGC_S_DYNAMIC_DEFAULT, for the purpose of denoting
values that are defaults in terms of the
On 2011-05-11 01:54, Greg Stark wrote:
To be fair about 3/4 of them were actually complaining about the lack
of some global materialized cache of the aggregate value. Covering
index-only scans are only going to be a linear speedup no matter how
large the factor it's not going to turn select
On Sat, May 7, 2011 at 10:48 PM, Robert Haas robertmh...@gmail.com wrote:
I was able to reproduce something very like this in unpatched master,
just by letting recovery pause at a named restore point, and then
resuming it.
I was able to reproduce the same problem even in 9.0. When the standby
101 - 111 of 111 matches
Mail list logo
