Bruce Momjian 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 sca
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:
variant_typ
On Tue, May 10, 2011 at 10:29 PM, Joseph Adams
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 me: if PostgreSQL func
2011/5/11 Joseph Adams :
> On Tue, May 10, 2011 at 10:29 PM, Joseph Adams
> 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
>
> Th
Tom Lane wrote:
> Bruce Momjian 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 wrote:
On Wed, 06 Apr 2011 20:04:37 +0200, Brar Piening 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 pgbison.bat in
my alt
On Wed, 11 May 2011 06:15:08 +0200, Brar Piening 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 your subscrip
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 (pgsql-hackers@postgres
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 th
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 count
On Sat, May 7, 2011 at 10:48 PM, Robert Haas 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
reaches the recover
Peter Eisentraut wrote:
> 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)?
I see it's not mentioned in t
101 - 112 of 112 matches
Mail list logo
