On Sun, Jan 09, 2011 at 04:10:25PM -0500, Tom Lane wrote:
> hstore's "hstore ?& text[]" operator is defined as "contains all", ie,
> it will return true if all the key names found in the text array are
> present in the hstore.
>
> ISTM that a sane definition of this operator would provide that if
On Sun, Jan 9, 2011 at 6:38 PM, Tom Lane wrote:
> or we could hack eqsel() to bound the no-stats estimate to a bit less
> than 1.
This seems like a pretty sensible thing to do. I can't immediately
imagine a situation in which 1.0 is a sensible selectivity estimate in
the no-stats case and 0.90 (
On Sun, Jan 9, 2011 at 7:47 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> If the SSI patch were to be accepted as is, REPEATABLE READ would
>> continue to provide the exact same snapshot isolation behavior which
>> both it and SERIALIZABLE do through 9.0, and SERIALIZABLE would
>> always use
On 1/9/11 3:38 PM, Tom Lane wrote:
> 1. Do nothing. The issue seems quite unlikely to affect anyone in the
> field, since in fact "use a seqscan" is probably the right answer
> anytime reltuples = 1; and anyway using a GIN index for plain equality
> is a corner case to begin with. However, it cou
"Kevin Grittner" writes:
> If the SSI patch were to be accepted as is, REPEATABLE READ would
> continue to provide the exact same snapshot isolation behavior which
> both it and SERIALIZABLE do through 9.0, and SERIALIZABLE would
> always use SSI on top of the snapshot isolation to prevent
> seria
Whilst fooling around with GIN over the past few days, I noticed the
following rather surprising behavior:
regression=# create table t1 (f1 int[]);
CREATE TABLE
regression=# insert into t1 values (array[42]);
INSERT 0 1
regression=# create index ti1 on t1 using gin (f1);
CREATE INDEX
regression=#
2011/1/7 Magnus Hagander :
> On Fri, Jan 7, 2011 at 01:47, Cédric Villemain
> wrote:
>> 2011/1/5 Magnus Hagander :
>>> On Wed, Jan 5, 2011 at 22:58, Dimitri Fontaine
>>> wrote:
Magnus Hagander writes:
> * Stefan mentiond it might be useful to put some
> posix_fadvise(POSIX_FADV_DON
Add an exemptor function for numeric. We store the scale in every datum, making
numeric(7,2)->numeric(8,3) unoptimizable. Precision changes work, though.
*** a/src/backend/utils/adt/numeric.c
--- b/src/backend/utils/adt/numeric.c
***
*** 712,717 numeric_send(PG_FUNCTION_ARGS)
---
Add exemptor functions for bit and varbit. These are probably the simplest
examples of the full range of optimizations. I would have used them as the test
case in the initial exemptor function patch if it were a more mainstream use
case.
*** a/src/backend/utils/adt/varbit.c
--- b/src/backend/util
Add exemptor functions to avoid rewrites for conversions involving the temporal
data types. I needed a find-last-set function for the interval_scale exemptor
function, so I imported one from FreeBSD. To improve timestamp<->timestamptz
when the timezone "is" UTC/GMT, I compare the current timezone
This patch removes ALTER TYPE rewrites in cases we can already prove valid. I
add a function GetCoerceExemptions() that walks an Expr according to rules
discussed in the design thread, simplified slightly pending additions in the
next patch. See the comment at that function for a refresher. I us
When ALTER TABLE rewrites a table, it reindexes, but the reindex does not
revalidate UNIQUE/EXCLUDE constraints. This behaves badly in cases like this,
neglecting to throw an error on the new UNIQUE violation:
CREATE TABLE t (c numeric UNIQUE);
INSERT INTO t VALUES (1.1),(1.2);
ALTER TABLE t ALTE
hstore's "hstore ?& text[]" operator is defined as "contains all", ie,
it will return true if all the key names found in the text array are
present in the hstore.
ISTM that a sane definition of this operator would provide that if the
array is empty, it returns true: every set contains the empty se
On 09.01.2011 07:05, Tom Lane wrote:
I just found out that the "benchmark" test script in
contrib/intarray/bench/ crashes HEAD in gistdoinsert() --- it looks like
it's trying to pop to a stack entry that isn't there.
Run it per the instructions in the intarray documentation:
$ createdb TEST
$ p
Patching:
patching file doc/src/sgml/func.sgml
Hunk #6 succeeded at 10567 (offset 1 line).
Hunk #7 succeeded at 10621 (offset 1 line).
Hunk #8 succeeded at 10721 (offset 1 line).
Hunk #9 succeeded at 10775 (offset 1 line).
patching file src/backend/nodes/makefuncs.c
patching file src/backend/parse
On Sun, Jan 09, 2011 at 12:07:49PM -0600, Kevin Grittner wrote:
> There's an issue where we don't seem to have consensus yet, so I
> figured I'd bounce it off the list.
>
> If the SSI patch were to be accepted as is, REPEATABLE READ would
> continue to provide the exact same snapshot isolation be
There's an issue where we don't seem to have consensus yet, so I
figured I'd bounce it off the list.
If the SSI patch were to be accepted as is, REPEATABLE READ would
continue to provide the exact same snapshot isolation behavior which
both it and SERIALIZABLE do through 9.0, and SERIALIZABLE wou
In going back through old emails to see what issues might have been
raised but not yet addressed for the SSI patch, I found the subject
issue described in a review by Jeff Davis here:
http://archives.postgresql.org/pgsql-hackers/2010-10/msg01159.php
I think this is already handled based on feed
On Sun, Jan 9, 2011 at 17:49, Tom Lane wrote:
> Magnus Hagander writes:
>> On Sun, Jan 9, 2011 at 17:31, Tom Lane wrote:
>>> I'd like to protest this patch as misguided. AFAICS it is a *seriously*
>
>> Uh, we install the file on Unix, so we should do the same on Windows.
>
> Well, my idea of ho
Magnus Hagander writes:
> On Sun, Jan 9, 2011 at 17:31, Tom Lane wrote:
>> I'd like to protest this patch as misguided. AFAICS it is a *seriously*
> Uh, we install the file on Unix, so we should do the same on Windows.
Well, my idea of how to fix that would be the other way 'round.
>> What we
On 1/5/11 6:19 PM, Florian Pflug wrote:
Sorry, but It isn't too intuitive. Minimally for me. Why you don't
thinking about simple functions with only positive arguments. There
are only four combinations. I don't think we must have only one super
function.
we need functionality for:
a) get first
On Sun, Jan 9, 2011 at 17:31, Tom Lane wrote:
> Magnus Hagander writes:
>> Properly install gram.h on MSVC builds
>> This file is now needed by pgAdmin builds, which started
>> failing since it was missing in the installer builds.
>
> I'd like to protest this patch as misguided. AFAICS it is a *
Magnus Hagander writes:
> Properly install gram.h on MSVC builds
> This file is now needed by pgAdmin builds, which started
> failing since it was missing in the installer builds.
I'd like to protest this patch as misguided. AFAICS it is a *seriously*
bad idea for pgAdmin to be including gram.h
On 09.01.2011 05:06, Robert Haas wrote:
On Sat, Jan 8, 2011 at 4:10 PM, Kevin Grittner
wrote:
Splitting out those three would leave src/backend/ and src/include/
which comes in at a svelte 5891 lines.
With a little more work I could split the three new files
(predicate.c, predicate.h, and pre
On Sun, 2011-01-09 at 12:52 +0100, Magnus Hagander wrote:
> One thing I noticed is that it gives an interesting property to my
> patch for streaming base backups - they now show up in
> pg_stat_replication, with a streaming location of 0/0.
>
> If the view is named pg_stat_replication, we probabl
2011/1/7 Garick Hamlin :
> On Thu, Jan 06, 2011 at 07:47:39PM -0500, Cédric Villemain wrote:
>> 2011/1/5 Magnus Hagander :
>> > On Wed, Jan 5, 2011 at 22:58, Dimitri Fontaine
>> > wrote:
>> >> Magnus Hagander writes:
>> >>> * Stefan mentiond it might be useful to put some
>> >>> posix_fadvise(PO
> A resource fork? Not sure what you mean, could you describe it in more
> detail?
Ooops, resource forks are a filesystem thing; we call them relation forks.
>From src/backend/storage/smgr/README:
Relation Forks
==
Since 8.4, a single smgr relation can be comprised of multiple physi
On Fri, Jan 7, 2011 at 22:21, Robert Haas wrote:
> On Fri, Jan 7, 2011 at 1:46 PM, Josh Berkus wrote:
>>
>>> To my way of thinking, pg_stat_walsender and pg_stat_walreceiver would
>>> be more clear than pg_stat_replication_master and
>>> pg_stat_replication_slave.
>>
>> Let's commit it so that so
On Sun, Jan 9, 2011 at 12:05, Hannu Krosing wrote:
> On 9.1.2011 10:44, Magnus Hagander wrote:
>>
>> On Sun, Jan 9, 2011 at 09:55, Hannu Krosing wrote:
>>>
>>> On 7.1.2011 15:45, Magnus Hagander wrote:
On Fri, Jan 7, 2011 at 02:15, Simon Riggs
wrote:
> One very useful fea
On 9.1.2011 10:44, Magnus Hagander wrote:
On Sun, Jan 9, 2011 at 09:55, Hannu Krosing wrote:
On 7.1.2011 15:45, Magnus Hagander wrote:
On Fri, Jan 7, 2011 at 02:15, Simon Riggswrote:
One very useful feature will be some way of confirming the number and
size of files to transfer, so that
On Sun, Jan 9, 2011 at 09:55, Hannu Krosing wrote:
> On 7.1.2011 15:45, Magnus Hagander wrote:
>>
>> On Fri, Jan 7, 2011 at 02:15, Simon Riggs wrote:
>>
>>> One very useful feature will be some way of confirming the number and
>>> size of files to transfer, so that the base backup client can find
On Sat, 2011-01-08 at 21:58 -0500, Robert Haas wrote:
> I mean, one semi-obvious possibility is to write one set of C
> functions that can have multiple SQL-level definitions bound to it.
> Then when the function is called, it can peek at flinfo->fn_oid to
> figure out which incarnation was called
On 7.1.2011 15:45, Magnus Hagander wrote:
On Fri, Jan 7, 2011 at 02:15, Simon Riggs wrote:
One very useful feature will be some way of confirming the number and
size of files to transfer, so that the base backup client can find out
the progress.
The patch already does this. Or rather, as it's
33 matches
Mail list logo
