> "Tom" == Tom Lane writes:
Tom> I think the concern over backwards compatibility here is probably
Tom> overblown; but if we're sufficiently worried about it, a possible
Tom> compromise is to invent a numeric_rounding_mode GUC, so that
Tom> people could get back the old behavior if they r
On Mar 27, 2015 6:41 PM, "Dima Ivanovskiy" wrote:
>
>
>> On Mar 27, 2015 11:08 AM, "Dima Ivanovskiy" wrote:
>> >
>> > Hello, I am Dmitrii, student of Moscow Institute of Physics and
Technology
>> >
>> > Abstract:
>> >
>> > I chose project "Indexing prolonged geometrical objects (i.e. boxes,
circl
Michael Paquier writes:
> It sounds appealing to switch the default behavior to something that
> is more IEEE-compliant, and not only for scale == 0. Now one can argue
> as well that changing the default is risky for existing applications,
> or the other way around that other RDBMs (?) are more co
On 03/26/2015 10:31 PM, Heikki Linnakangas wrote:
I've pushed Anastasia's patch to support index-only scans with GiST, and
it's time to add opclasses support for all the opclasses that are not
lossy. I think at least all the btree_gist opclasses need to be
supported, it would be pretty surprising
Hi all,
A couple of days ago a bug has showed up regarding rounding of float here:
http://www.postgresql.org/message-id/flat/20150320194337.2573.72...@wrigleys.postgresql.org#20150320194337.2573.72...@wrigleys.postgresql.org
The result being that the version of rint() shipped in src/port was
not I
>On Mar 27, 2015 11:08 AM, "Dima Ivanovskiy" < dima...@mail.ru > wrote:
>>
>> Hello, I am Dmitrii, student of Moscow Institute of Physics and Technology
>>
>> Abstract:
>>
>> I chose project "Indexing prolonged geometrical objects (i.e. boxes,
>> circles, polygons, not points) with SP-GiST by map
On Wed, Mar 25, 2015 at 11:07 PM, Tom Lane wrote:
> Anastasia Lubennikova writes:
> > 2015-03-24 18:01 GMT+04:00 Tom Lane :
> >> I wonder whether it'd be possible to teach GIN to support index_getnext
> >> instead. Initially it would probably work only for cases where the
> >> index didn't have
Hi all,
I'm tweaking some autovacuum settings in a table with high write usage but
with ALTER TABLE .. SET ( .. ) this task was impossible, so I did a catalog
update (pg_class) to change reloptions.
Maybe it's a stupid doubt, but why we need to get an AccessExclusiveLock on
relation to set relop
2015-03-26 23:26 GMT+01:00 David Fetter :
> Folks,
>
> For reasons unclear, dates before the Common Era are disallowed in
> make_date(), even though about 2/3 of the underlying data type's range
> up until the present time fits that description.
>
> Please find attached a patch fixing same.
>
+1
On Mar 27, 2015 11:08 AM, "Dima Ivanovskiy" wrote:
>
> Hello, I am Dmitrii, student of Moscow Institute of Physics and Technology
>
> Abstract:
>
> I chose project "Indexing prolonged geometrical objects (i.e. boxes,
circles, polygons, not points) with SP-GiST by mapping to 4d-space".
> According
Hello, I am Dmitrii, student of Moscow Institute of Physics and Technology
Abstract:
I chose project "Indexing prolonged geometrical objects (i.e. boxes, circles,
polygons, not points) with SP-GiST by mapping to 4d-space".
According to the presentation
https://www.pgcon.org/2011/schedule/attach
Rajeev rastogi writes:
> What is Pluggable Parser:
> It is an option for users to select a different kind of parser to evaluate
> PostgreSQL for their business logic without much manual effort.
> Why do we need?
> As of now migration from other databases to PostgreSQL requires manual effort
> o
Antonin Houska wrote:
> I'm still testing it. especially the concurrent access. There are probably
> bugs in the code, but it can help understand what I mean.
I've traced the most important cases of concurrent insertion into a bucket
split of which is in progress. A few related bugs fixed. Some t
Hi all.
I have described [0] a problem with delaying replicas after vacuuming a
relation with big btree index. It stucks in replaying WAL record of type
XLOG_BTREE_VACUUM like that (with lastBlockVacuumed 0):
rmgr: Btree len (rec/tot): 20/52, tx: 0, lsn:
4115/56126DC0, p
What is Pluggable Parser:
It is an option for users to select a different kind of parser to evaluate
PostgreSQL for their business logic without much manual effort.
Why do we need?
As of now migration from other databases to PostgreSQL requires manual effort
of translating SQL & PL/SQL to Postgr
On Fri, Mar 13, 2015 at 1:33 PM, Peter Eisentraut wrote:
> On 3/4/15 1:34 AM, Haribabu Kommi wrote:
>> On Wed, Mar 4, 2015 at 12:35 PM, Haribabu Kommi
>> wrote:
>>> + foreach(line, parsed_hba_lines)
>>>
>>> In the above for loop it is better to add "check_for_interrupts" to
>>> avoid it looping
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18-03-2015 17:18, Svenne Krap wrote:
>
> I still need to check against the standard and I will run it against a
non-trivival production load... hopefully I will finish up my review
shortly after the weekend...
I am still on it, but a little dela
Hi,
I have written a C program which reads from 3 files(Each file is table
having 2 columns and thousands of rows).The program is used to join those 3
tables and the algorithm which I have written will work only for those 3
files. Now I want to test this program for postgres. Can someone tell me
h
18 matches
Mail list logo
