Tom Duffey wrote (on -general):
> To bring closure to this thread, my whole problem was caused by not knowing
> about the
> extra_float_digits setting. We have a script that uses COPY to transfer a
> subset of rows from a very
> large production table to a test table. The script was not setting
On Thu, Feb 28, 2013 at 7:52 PM, Kevin Grittner wrote:
> Barring a sudden confluence of opinion, I will go with TRUNCATE for
> the initial spelling. I tend to favor that spelling for several
> reasons. One was the size of the patch needed to add the opposite
> of REFRESH to the backend code:
FW
Ants Aasma wrote:
> Kevin Grittner wrote:
>> Barring a sudden confluence of opinion, I will go with TRUNCATE
>> for the initial spelling. I tend to favor that spelling for
>> several reasons. One was the size of the patch needed to add
>> the opposite of REFRESH to the backend code:
>
> FWIW, I
On Wed, Feb 13, 2013 at 5:55 PM, Alexander Korotkov wrote:
> On Wed, Feb 13, 2013 at 5:28 PM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>> On 04.01.2013 10:42, Alexander Korotkov wrote:
>>
>>> /*
>>> * Calculate selectivity of "&&" operator using histograms of range
>>> lower bound
On Fri, Mar 1, 2013 at 4:18 PM, Kevin Grittner wrote:
> Personally, I don't understand why anyone would want updateable
> materialized views. That's probably because 99% of the cases where
> I've seen that someone wanted them, they wanted them updated to
> match the underlying data using some tec
I spotted some low-hanging fruit in the pglz compression routine. It
uses a hash table to keep track of string prefixes it has seen:
#define PGLZ_HISTORY_LISTS 8192/* must be power of 2 */
#define PGLZ_HISTORY_SIZE 4096
/* --
* Statically allocated work a
On 2/28/13 3:34 PM, Robert Haas wrote:
> It's
> possible to vastly reduce the size of the scanner output, and
> therefore of gram.c, by running flex with -Cf rather than -CF, which
> changes the table representation completely. I assume there is a
> sound performance reason why we don't do this, b
Heikki Linnakangas wrote:
> I spotted this while looking at Amit's WAL update delta encoding
> patch. My earlier suggestion to just use the pglz compressor for the
> delta encoding didn't work too well because the pglz compressor was
> too expensive, especially for small values. This patch might h
On 01.03.2013 17:37, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
In summary, this seems like a pretty clear win for short values, and
a wash for long values. Not surprising, as this greatly lowers the
startup cost of pglz_compress(). We're past feature freeze, but how
would people feel abou
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Surely we're not past feature freeze. If we were, we'd have to reject
> all remaining patches from the commitfest, which is not what we want to
> do at this stage, is it?
Actually, I think we're getting very close to exactly that point- we're
n
On Fri, Feb 22, 2013 at 11:50 AM, David E. Wheeler
wrote:
> On Feb 22, 2013, at 9:37 AM, Robert Haas wrote:
>
>> What I think is NOT tolerable is choosing a set of short but arbitrary
>> names which are different from anything that we have now and
>> pretending that we'll want to use those again
On Sun, Feb 24, 2013 at 10:30 PM, Greg Smith wrote:
> Attached is some bit rot updates to the checksums patches. The replace-tli
> one still works fine
I rather badly want this feature, and if the open issues with the
patch has hit zero, I'm thinking about applying it, shipping it, and
turni
On Fri, Mar 1, 2013 at 12:57 PM, Michael Paquier
wrote:
> On Thu, Feb 28, 2013 at 11:26 PM, Fujii Masao wrote:
>>
>> I found one problem in the latest patch. I got the segmentation fault
>> when I executed the following SQLs.
>>
>> CREATE TABLE hoge (i int);
>> CREATE INDEX hogeidx ON hoge(abs(i)
> As I stepped up to work on the CF and then became immediately swamped in
> other work I bear some of the responsibility for not keeping things
> rolling.
Just FYI, this is exactly why I wanted a 2nd CF manager for this CF.
> It'd be really good if anyone with a patch in the CF could follow up
ranger" error:
>
> select format('|%*s|', -2147483648, 'foo');
> Result: |foo|
>
> because -(-2147483648) = 0 in signed 32-bit integers.
fixed - next other overflow check added
Regards
Pavel
>
> Apart from that, I didn't find any problems
On Mon, Jan 14, 2013 at 06:51:05AM -0500, Peter Eisentraut wrote:
> In multi-arch OS installations, using a single foo-config script to find
> libraries is problematic, because you don't know which architecture it
> will point to, and you can't choose which one you want. Using
> pkg-config is bett
On Sat, Mar 2, 2013 at 2:43 AM, Fujii Masao wrote:
>> Fixed in this new patch. Thanks for catching that.
After make installcheck finished, I connected to the "regression" database
and issued "REINDEX DATABASE CONCURRENTLY regression", then
I got the error:
ERROR: constraints cannot have index e
2013/2/27 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> I don't agree so it works well - you cannot use short type names is
>> significant issue
>
> This is for psql. In what use-case do you see that being a serious
> limitation?
>
> I might support having psql be able to f
REINDEX CONCURRENTLY resets the statistics in pg_stat_user_indexes,
whereas plain REINDEX does not. I think they should be preserved in
either case.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgs
Dimitri Fontaine escribió:
> The good news is that the patch to do that has already been sent on this
> list, and got reviewed in details by Álvaro who did offer incremental
> changes. Version 3 of that patch is to be found in:
>
> http://www.postgresql.org/message-id/m2fw19n1hr@2ndquadrant
* Jeff Janes:
> Does the kernel really read a data block from disk into memory in
> order to immediately overwrite it? I would have thought it would
> optimize that away, at least if the writes are sized and aligned to
> 512 or 1024 bytes blocks (which WAL should be).
With Linux, you'd have to u
Alex Hunsaker writes:
> On Tue, Feb 26, 2013 at 3:56 PM, Tom Lane wrote:
>> I'm inclined to think the right fix is to make a small memory context
>> for each prepared plan made by plperl_spi_prepare(). The qdesc for it
>> could be made right in the context (getting rid of the unchecked
>> malloc
On Fri, Mar 1, 2013 at 7:38 PM, Tom Lane wrote:
>
> Alex Hunsaker writes:
>
> Applied with some fixes.
Thanks! Your version looks much better than mine.
> > One annonce is it still leaks :-(.
>
> I fixed that, at least for the function-lifespan leakage from
> spi_prepare() --- is that what you
On 03/02/2013 02:36 AM, Josh Berkus wrote:
>> As I stepped up to work on the CF and then became immediately swamped in
>> other work I bear some of the responsibility for not keeping things
>> rolling.
> Just FYI, this is exactly why I wanted a 2nd CF manager for this CF.
>
>> It'd be really good i
24 matches
Mail list logo
