I saw some strange results:
postgres=# select '1.1'::numeric = '1.1'::float8;
?column?
--
t
(1 row)
postgres=# select '1.1'::numeric = '1.1'::float4;
?column?
--
f
(1 row)
When I looked into it, I saw that the numeric is being cast to a float8,
making the first statement
Hello,
Version one is k' = 1 + (a * k + b) modulo n with a prime with
respect to n, n being the number of keys. This is nearly possible,
but for the modulo operator which is currently missing, and that I'm
planning to submit for this very reason, but probably another time.
That's pretty
Hi,
2014-08-01 16:26 GMT+09:00 Fabien COELHO coe...@cri.ensmp.fr
Maybe somebody who knows more math than I do (like you, probably!) can
come up with something more clever.
I can certainly suggest other formula, but that does not mean beautiful
code, thus would probably be rejected. I'll
Hi, hackers!
I work on a GSoC project Index-only scans for GIST
https://wiki.postgresql.org/wiki/Support_for_Index-only_scans_for_GIST_GSoC_2014
Repository is
https://github.com/lubennikovaav/postgres/tree/indexonlygist2
Patch is in attachments.
It includes index-only scans for multicolumn GIST
Hello, this is the new version which is complete to some extent
of parallelism based on postgres_fdw.
This compares the costs for parallel and non-parallel execution
and choose parallel one if it is faster by some extent specified
by GUCs. The attached files are,
Hello,
Hello, this is the new version which is complete to some extent
of parallelism based on postgres_fdw.
This compares the costs for parallel and non-parallel execution
and choose parallel one if it is faster by some extent specified
by GUCs. The attached files are,
On Tue, Jul 29, 2014 at 1:35 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
David Rowley wrote:
I've also been looking at the isolation tests and I see that you've
added a
series of tests for NOWAIT. I was wondering why you did that as that's
really existing code, probably if you
On Tue, Jul 29, 2014 at 9:48 AM, Thomas Munro mu...@ip9.org wrote:
On 27 July 2014 23:19, Thomas Munro mu...@ip9.org wrote:
On the subject of isolation tests, I think skip-locked.spec is only
producing schedules that reach third of the three 'return
HeapTupleWouldBlock' statements in
On 07/30/2014 07:46 PM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Wed, Jul 30, 2014 at 01:29:31PM -0400, Tom Lane wrote:
I don't find it all that odd. We should not be encouraging routine
database-wide reindexes.
Uh, do we encourage database-wide VACUUM FULL or CLUSTER, as
Hi,
In 9.2, pg_receivexlog -v has emitted the messages as follows at the
end of each WAL file.
pg_receivexlog: finished segment at 0/200 (timeline 1)
pg_receivexlog: finished segment at 0/300 (timeline 1)
pg_receivexlog: finished segment at 0/400 (timeline 1)
But, while reviewing
Jeff Davis pg...@j-davis.com wrote:
I saw some strange results:
postgres=# select '1.1'::numeric = '1.1'::float8;
?column?
--
t
(1 row)
postgres=# select '1.1'::numeric = '1.1'::float4;
?column?
--
f
(1 row)
The part I find strange is that the first one evaluates to
Kevin Grittner kgri...@ymail.com writes:
Jeff Davis pg...@j-davis.com wrote:
I saw some strange results:
The part I find strange is that the first one evaluates to true,
since numeric can exactly represent 1.1 and float8 cannot.
The reason is that the numeric input is converted to float8 for
On 1 August 2014 10:37, David Rowley dgrowle...@gmail.com wrote:
* skip-locked-2.spec
# s2 againt skips because it can't acquired a multi-xact lock
againt should be again
Fixed.
also mixed use of multixact and multi-xact, probably would be better to
stick to just 1.
Changed to multixact
On Fri, Aug 1, 2014 at 12:35 AM, Amit Kapila amit.kapil...@gmail.com wrote:
c) the map is not crash safe by design, because it needs only for
incremental backup to track what blocks needs to be backuped, not for
consistency or recovery of the whole cluster, so it's not an heavy cost for
the
On Fri, Aug 1, 2014 at 4:58 AM, Anastasia Lubennikova
lubennikov...@gmail.com wrote:
Hi, hackers!
I work on a GSoC project Index-only scans for GIST
https://wiki.postgresql.org/wiki/Support_for_Index-only_scans_for_GIST_GSoC_2014
Repository is
Here's a new version of this patch, please review.
I've cleaned up a lot of stuff, fixed all the bugs reported so far, and
a bunch of others I found myself while testing.
I'm not going to explain again what the patch does; the README and
comments should now be complete enough to explain how
2014-08-01 18:20 GMT+02:00 Claudio Freire klaussfre...@gmail.com:
On Fri, Aug 1, 2014 at 12:35 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
c) the map is not crash safe by design, because it needs only for
incremental backup to track what blocks needs to be backuped, not for
consistency
Thank you for comment
Patch is already added in Performance topic.
2014-08-01 20:25 GMT+04:00 FabrÃzio de Royes Mello fabriziome...@gmail.com
:
On Fri, Aug 1, 2014 at 4:58 AM, Anastasia Lubennikova
lubennikov...@gmail.com wrote:
Hi, hackers!
I work on a GSoC project Index-only scans
On Fri, Aug 1, 2014 at 8:35 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
In 9.2, pg_receivexlog -v has emitted the messages as follows at the
end of each WAL file.
pg_receivexlog: finished segment at 0/200 (timeline 1)
pg_receivexlog: finished segment at 0/300 (timeline 1)
On Fri, Aug 1, 2014 at 1:43 PM, desmodemone desmodem...@gmail.com wrote:
2014-08-01 18:20 GMT+02:00 Claudio Freire klaussfre...@gmail.com:
On Fri, Aug 1, 2014 at 12:35 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
c) the map is not crash safe by design, because it needs only for
On 07/11/2014 08:39 PM, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
I did again the refactoring you did back in 2006, patch attached.
One thing I did differently: I moved the raw, non-encrypted,
read/write functions to separate functions: pqsecure_raw_read and
pqsecure_raw_write. Those
On 07/08/2014 08:11 PM, Jeff Janes wrote:
Is there some recipe for testing the 0002 patch? Can it be tested on an
MinGW environment, or does it need to use the MicroSoft supplied compilers?
I used MSVC. It ought to work with MinGW, I think, although you might
need to tweak the Makefiles to
This patch is pretty trivial.
Add modulo operator to pgbench.
This is useful to compute a permutation for tests with non uniform
accesses (exponential or gaussian), so as to avoid trivial correlations
between neighbour keys.
--
Fabien.diff --git a/contrib/pgbench/pgbench.c
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
Jeff Davis pg...@j-davis.com wrote:
I saw some strange results:
The part I find strange is that the first one evaluates to true,
since numeric can exactly represent 1.1 and float8 cannot.
The reason is that the
Kevin Grittner kgri...@ymail.com writes:
It would be more consistent, ISTM, to cast
float8 to float4 when those are compared, and to cast numeric to
whichever type is on the other side of the comparison operator.
I would vote against that on the grounds of greatly increased risk
of overflow
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
It would be more consistent, ISTM, to cast
float8 to float4 when those are compared, and to cast numeric to
whichever type is on the other side of the comparison operator.
I would vote against that on the grounds of
Hackers,
Since Gabrielle has improved archiving with pg_stat_archiver in 9.4, I'd
like to go further and improve the usability of pg_stop_backup().
However, based on my IRC discussion with Vik, there might not be
consensus on what the right behavior *should* be. This is for 9.5, of
course.
On Thu, Jul 31, 2014 at 1:12 PM, Peter Geoghegan p...@heroku.com wrote:
Abbreviated it is.
Attached revision uses new terminology. I have abandoned configure
tests entirely, preferring to explicitly discriminate against Mac OS X
(Darwin) as a platform with a known odd locale implementation, just
For a long time (since version 8.0), PostgreSQL has adopted the logical
barriers for centuries and millenniums in these functions. The calendar
starts millennium and century 1 on year 1, directly after 1 BC.
Unfortunately decades are still reported rather simplistically by
dividing the year by
ed802e7 seems to have broken the windows builds.
.\contrib\pgbench\pgbench.c(530): error C2065: 'M_PI' : undeclared
identifier
The attached fixes the problem. It seems all other uses of M_PI have
added the same code to the .c file rather than any header file,
perhaps a better patch would fix up
Mike Swanson wrote
For a long time (since version 8.0), PostgreSQL has adopted the logical
barriers for centuries and millenniums in these functions. The calendar
starts millennium and century 1 on year 1, directly after 1 BC.
Unfortunately decades are still reported rather simplistically by
On Sat, Aug 2, 2014 at 3:55 AM, Thomas Munro mu...@ip9.org wrote:
On 1 August 2014 10:37, David Rowley dgrowle...@gmail.com wrote:
Apart from this I can't see any other problems with the patch and I'd be
very inclined, once the above are fixed up to mark the patch ready for
commiter.
On 08/01/2014 05:32 PM, David G Johnston wrote:
Any supporting arguments for 1-10 = 1st decade other than technical
perfection? I guess if you use data around and before 1AD you care about
this more, and rightly so, but given sound arguments for both methods the
one more useful to more users
On 02/08/14 12:32, David G Johnston wrote:
Mike Swanson wrote
For a long time (since version 8.0), PostgreSQL has adopted the logical
barriers for centuries and millenniums in these functions. The calendar
starts millennium and century 1 on year 1, directly after 1 BC.
Unfortunately decades
On Fri, Aug 1, 2014 at 8:15 PM, Gavin Flower gavinflo...@archidevsys.co.nz
wrote:
On 02/08/14 12:32, David G Johnston wrote:
Any supporting arguments for 1-10 = 1st decade other than technical
perfection? I guess if you use data around and before 1AD you care about
this more, and rightly
On Fri, Aug 01, 2014 at 04:00:11PM -0700, Peter Geoghegan wrote:
Since Robert did not give a
reason for discussing the basic fmgr-elision patch despite having
already discussed it a couple of years ago, I have not split the patch
into two (if I did, the first patch would be virtually identical
On Fri, Aug 1, 2014 at 8:57 PM, Noah Misch n...@leadboat.com wrote:
Robert, Heikki and maybe Alvaro requested and/or explained this split back in
April. The fact that the would-be first patch was discussed and rejected in
the past does not counter that request. (I voted against Robert's 2012
On Sat, 2014-08-02 at 15:15 +1200, Gavin Flower wrote:
Since there was no year zero: then it follows that the first decade
comprises years 1 to 10, and the current Millennium started in 2001 - or
am I being too logical??? :-)
This is pretty much the reason I'm sending this patch, because it
38 matches
Mail list logo
