On Tue, Oct 29, 2013 at 9:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Sergey Konoplev gray...@gmail.com writes:
On Wed, Oct 23, 2013 at 11:03 PM, Abhijit Menon-Sen a...@2ndquadrant.com
wrote:
This is a slightly reworked version of the patch submitted by Richard
Poole last month, which was
On Tue, Oct 29, 2013 at 11:08:05PM -0700, Sergey Konoplev wrote:
On Tue, Oct 29, 2013 at 9:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Sergey Konoplev gray...@gmail.com writes:
On Wed, Oct 23, 2013 at 11:03 PM, Abhijit Menon-Sen a...@2ndquadrant.com
wrote:
This is a slightly reworked
On Wed, Oct 30, 2013 at 10:16:57AM +0530, Abhijit Menon-Sen wrote:
At 2013-10-24 16:06:19 +0300, hlinnakan...@vmware.com wrote:
Let's get rid of the rounding.
I share Andres's concern that the bug is present in various recent
kernels that are going to stick around for quite some time.
At 2013-10-30 00:10:39 -0700, da...@fetter.org wrote:
How about documenting that 2MB is the quantum (OK, we'll say
indivisible unit or smallest division or something) and failing
with a message to that effect if someone tries to set it otherwise?
I don't think you understand the problem.
Hmm, you realise Alvaro is working on MinMax indexes in this release?
They are very efficient with regard to index inserts and specially
designed for use on large tables.
Prior work by Heikki on Grouped Item Tuples was a way of reducing the
size of indexes, yet still allowing uniqueness
On Mon, Sep 30, 2013 at 10:10 PM, David Rowley dgrowle...@gmail.com wrote:
On Sat, Sep 28, 2013 at 9:44 PM, David Rowley dgrowle...@gmail.comwrote:
I did some benchmarking earlier in the week for the new patch which was
just commited to allow formatting in the log_line_prefix string. In
On 30 October 2013 07:55, Leonardo Francalanci m_li...@yahoo.it wrote:
Hmm, you realise Alvaro is working on MinMax indexes in this release?
They are very efficient with regard to index inserts and specially
designed for use on large tables.
Prior work by Heikki on Grouped Item Tuples was a
Presumably the data you are inserting isn't actually random. Please
describe the use case you are considering in more detail and some view
on how frequent that is, with some examples. Once we understand the
use case and agree it is important, we might solve problems.
Collecting calls data
On 30 October 2013 10:35, Leonardo Francalanci m_li...@yahoo.it wrote:
Presumably the data you are inserting isn't actually random. Please
describe the use case you are considering in more detail and some view
on how frequent that is, with some examples. Once we understand the
use case and
What is the reason for needing such fast access to individual groups
of records? Sure sounds like the NSA or similar ;-)
Users need to search all calls originated from/to a user or from/to a specific
mobile phone to answer/analyze customers' probl... ok, I give up: I work for
the NSA ;)
In
On 2013-10-30 12:08, Simon Riggs wrote:
effort to replicate what you have already achieved? Who would pay?
The NSA, obviously ;-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Oct 30, 2013 at 8:22 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Oct 30, 2013 at 1:22 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Wed, Oct 30, 2013 at 12:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The last two buildfarm runs on frogmouth have failed in initdb,
like this:
On Wed, Oct 30, 2013 at 1:22 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Wed, Oct 30, 2013 at 12:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The last two buildfarm runs on frogmouth have failed in initdb,
like this:
creating directory
Hello,
For a certain reason, I need to build PostgreSQL on Windows with OSSP UUID
support to use UUID for primary keys. I have to use Visual Studio 2010.
The original source code for OSSP UUID and its fork for Windows can be
downloaded from:
http://www.ossp.org/pkg/lib/uuid/
Hello,
# Sorry, Saito san' address doesn't seem to exist, so excuse for sending
again
For a certain reason, I need to build PostgreSQL on Windows with OSSP UUID
support to use UUID for primary keys. I have to use Visual Studio 2010.
The original source code for OSSP UUID and its fork for
On Tue, Oct 29, 2013 at 3:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The last two buildfarm runs on frogmouth have failed in initdb,
like this:
creating directory
d:/mingw-bf/root/HEAD/pgsql.2492/src/test/regress/./tmp_check/data ... ok
creating subdirectories ... ok
selecting default
On 2013-10-30 08:45:03 -0400, Robert Haas wrote:
If I'm reading this correctly, the last three runs on frogmouth have
all failed, and all of them have failed with a complaint about,
specifically, Global/PostgreSQL.851401618. Now, that really shouldn't
be happening, because the code to choose
On Wed, Oct 30, 2013 at 8:22 AM, Robert Haas robertmh...@gmail.com wrote:
I find it hard to believe this is the right fix. I know we have
similar code in win32_shmem.c, but surely if size is a 32-bit unsigned
quantity then size 0 is simply 0 anyway.
Gosh, I stand corrected. According to
On Wed, Oct 30, 2013 at 8:47 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-30 08:45:03 -0400, Robert Haas wrote:
If I'm reading this correctly, the last three runs on frogmouth have
all failed, and all of them have failed with a complaint about,
specifically,
On Wed, Oct 30, 2013 at 4:51 AM, David Rowley dgrowle...@gmail.com wrote:
I've attached a re-based version of this.
I don't see any compelling reason not to commit this. Does anyone
wish to object?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Robert Haas robertmh...@gmail.com writes:
If I'm reading this correctly, the last three runs on frogmouth have
all failed, and all of them have failed with a complaint about,
specifically, Global/PostgreSQL.851401618. Now, that really shouldn't
be happening, because the code to choose that
On 2013-10-30 09:26:42 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
If I'm reading this correctly, the last three runs on frogmouth have
all failed, and all of them have failed with a complaint about,
specifically, Global/PostgreSQL.851401618. Now, that really shouldn't
Andres Freund and...@2ndquadrant.com writes:
On 2013-10-30 09:26:42 -0400, Tom Lane wrote:
Isn't this complaining about the main shm segment, not a DSM extension?
Don't think so, that has a : in the name.
If it *isn't* about the main memory segment, what the hell are we doing
creating random
Robert Haas escribió:
On Wed, Oct 30, 2013 at 4:51 AM, David Rowley dgrowle...@gmail.com wrote:
I've attached a re-based version of this.
I don't see any compelling reason not to commit this. Does anyone
wish to object?
I think a blanket substitution of places that currently have %s might
On 30 October 2013 11:23, Leonardo Francalanci m_li...@yahoo.it wrote:
What is the reason for needing such fast access to individual groups
of records? Sure sounds like the NSA or similar ;-)
Users need to search all calls originated from/to a user or from/to a
specific mobile phone to
On 2013-10-30 10:52:05 -0300, Alvaro Herrera wrote:
Robert Haas escribió:
On Wed, Oct 30, 2013 at 4:51 AM, David Rowley dgrowle...@gmail.com wrote:
I've attached a re-based version of this.
I don't see any compelling reason not to commit this. Does anyone
wish to object?
I think a
LSM-trees seem patent free
I'm no expert, and I gave it just a look some time ago: it looked to me very
complicated to get right... and as far as I remember you don't get that much
gain, unless you go multi-level which would complicate things further
Please somebody advise patent status of
Hi MauMau-san
it my bug patch applied to ver 1.6.2sorry..
then, I made the next patch is there, please see,
http://winpg.jp/~saito/pg_work/OSSP_win32/
I will be adjusted and Ralf-san again.
best regards,
Hiroshi Saito
(2013/10/30 21:45), MauMau wrote:
Hello,
# Sorry, Saito san' address
On 30 October 2013 11:23, Leonardo Francalanci m_li...@yahoo.it wrote:
In terms of generality, do you think its worth a man year of developer
effort to replicate what you have already achieved? Who would pay?
I work on an application that does exactly what Leonardo described. We hit
the
Abhijit Menon-Sen a...@2ndquadrant.com writes:
As a compromise, perhaps we can unconditionally round the size up to be
a multiple of 2MB? That way, we can use huge pages more often, but also
avoid putting in a lot of code and effort into the workaround and waste
only a little space (if any at
Sergey Konoplev gray...@gmail.com writes:
On Tue, Oct 29, 2013 at 9:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Say what? There's never been any hugepages support in Postgres.
There were an ability to back shared memory with hugepages when using
=9.2. I use it on ~30 servers for several years
On Wed, Oct 30, 2013 at 9:23 AM, Leonardo Francalanci m_li...@yahoo.it wrote:
LSM-trees seem patent free
I'm no expert, and I gave it just a look some time ago: it looked to me very
complicated to get right... and as far as I remember you don't get that much
gain, unless you go multi-level
On Wed, Oct 30, 2013 at 3:35 AM, Leonardo Francalanci m_li...@yahoo.itwrote:
Presumably the data you are inserting isn't actually random. Please
describe the use case you are considering in more detail and some view
on how frequent that is, with some examples. Once we understand the
use
Andres Freund escribió:
On 2013-10-30 10:52:05 -0300, Alvaro Herrera wrote:
Robert Haas escribió:
On Wed, Oct 30, 2013 at 4:51 AM, David Rowley dgrowle...@gmail.com
wrote:
I've attached a re-based version of this.
I don't see any compelling reason not to commit this. Does
Hiroshi Saito escribió:
Hi MauMau-san
it my bug patch applied to ver 1.6.2sorry..
then, I made the next patch is there, please see,
http://winpg.jp/~saito/pg_work/OSSP_win32/
I will be adjusted and Ralf-san again.
At this point, I think we need to consider ossp-uuid as dead code.
On Wed, Oct 30, 2013 at 4:23 AM, Leonardo Francalanci m_li...@yahoo.itwrote:
1) I haven't achieved what I need: realtime indexing. I can't query the
current 15 minutes table efficiently. Plus, K*log(N) is not that great
when you have a lot of K.
Are partitions read-only once time has moved
On Wed, Oct 30, 2013 at 9:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
If I'm reading this correctly, the last three runs on frogmouth have
all failed, and all of them have failed with a complaint about,
specifically, Global/PostgreSQL.851401618. Now,
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 30, 2013 at 9:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Also, why is the error not enough space, rather than something about
a collision? And if this is the explanation, why didn't the previous
runs probing for allowable shmem size fail?
Alvaro Herrera alvhe...@2ndquadrant.com writes:
At this point, I think we need to consider ossp-uuid as dead code.
Yeah, but what shall we replace it with? And can we preserve the
API contrib/uuid-ossp offers? (Maybe we shouldn't even try, but
just deprecate that module and start fresh.)
Robert Haas robertmh...@gmail.com writes:
Yeah, I think that's probably what it is. There's PostmasterRandom()
to initialize the random-number generator on first use, but that
doesn't help if some other module calls random(). I wonder if we
ought to just get rid of PostmasterRandom() and
On Wed, Oct 30, 2013 at 9:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-10-30 09:26:42 -0400, Tom Lane wrote:
Isn't this complaining about the main shm segment, not a DSM extension?
Don't think so, that has a : in the name.
If it *isn't*
On 10/30/2013 12:43 PM, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
At this point, I think we need to consider ossp-uuid as dead code.
Yeah, but what shall we replace it with? And can we preserve the
API contrib/uuid-ossp offers? (Maybe we shouldn't even try, but
just
Jeff Janes wrote
The index insertions should be fast until the size of the active part of
the indexes being inserted into exceeds shared_buffers by some amount
(what
that amount is would depend on how much dirty data the kernel is willing
to
allow in the page cache before it starts suffering
On Wed, Oct 30, 2013 at 12:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah, I think that's probably what it is. There's PostmasterRandom()
to initialize the random-number generator on first use, but that
doesn't help if some other module calls
Jeff Janes wrote
Are partitions read-only once time has moved on, or can stragglers show up
that need to be inserted into older partitions?
You could periodically merge older partitions into larger tables, index
those aggregated tables, then transactionally disinherit the old
partitions
Point being: hardware is marching along pretty fast (after 20+ years
of stagnation) and it's dangerous (IMO) to make big software
investments based on the situation on the ground *today*.
Yes, that's a good point.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Jeff Janes wrote
You could periodically merge older partitions into larger tables, index
those aggregated tables, then transactionally disinherit the old
partitions
and inherit the new aggregated one. This would keep the value of K down,
at the expense of re-writing data multiple times (but
At 2013-10-30 11:04:36 -0400, t...@sss.pgh.pa.us wrote:
As a compromise, perhaps we can unconditionally round the size up to be
a multiple of 2MB? […]
That sounds reasonably painless to me.
Here's a patch that does that and adds a DEBUG1 log message when we try
with MAP_HUGETLB and fail
On 2013-10-30 22:39:20 +0530, Abhijit Menon-Sen wrote:
At 2013-10-30 11:04:36 -0400, t...@sss.pgh.pa.us wrote:
As a compromise, perhaps we can unconditionally round the size up to be
a multiple of 2MB? […]
That sounds reasonably painless to me.
Here's a patch that does that and
On Wed, Oct 30, 2013 at 8:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Sergey Konoplev gray...@gmail.com writes:
On Tue, Oct 29, 2013 at 9:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Say what? There's never been any hugepages support in Postgres.
There were an ability to back shared memory with
On Wed, Oct 30, 2013 at 9:54 AM, Leonardo Francalanci m_li...@yahoo.itwrote:
Jeff Janes wrote
The index insertions should be fast until the size of the active part of
the indexes being inserted into exceeds shared_buffers by some amount
(what
that amount is would depend on how much dirty
On Wed, Oct 30, 2013 at 10:53 AM, Simon Riggs si...@2ndquadrant.com wrote:
LSM-tree also covers the goal of maintaining just 2 sub-trees and a
concurrent process of merging sub-trees. That sounds like it would
take a lot of additional time to get right and would need some
off-line process to
On 31/10/13 06:46, Jeff Janes wrote:
On Wed, Oct 30, 2013 at 9:54 AM, Leonardo Francalanci
m_li...@yahoo.it mailto:m_li...@yahoo.it wrote:
Jeff Janes wrote
The index insertions should be fast until the size of the active
part of
the indexes being inserted into exceeds
Sergey Konoplev escribió:
On Wed, Oct 30, 2013 at 8:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Sergey Konoplev gray...@gmail.com writes:
There were an ability to back shared memory with hugepages when using
=9.2. I use it on ~30 servers for several years and it brings 8-17%
of performance
On Wed, Oct 30, 2013 at 11:50 AM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
There were an ability to back shared memory with hugepages when using
=9.2. I use it on ~30 servers for several years and it brings 8-17%
of performance depending on the memory size. Here you will find
several
Alvaro Herrera escribió:
Sergey Konoplev escribió:
I wasn't talking about a built-in support. It was about an ability (a
way) to back sh_buf with hugepages.
Then what you need is to set
dynamic_shared_memory_type = sysv
in postgresql.conf.
The above is mistaken -- there's no way to
On Wed, Oct 30, 2013 at 12:17 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I wasn't talking about a built-in support. It was about an ability (a
way) to back sh_buf with hugepages.
Then what you need is to set
dynamic_shared_memory_type = sysv
in postgresql.conf.
The above is
From: Hiroshi Saito hiro...@winpg.jp
it my bug patch applied to ver 1.6.2sorry..
then, I made the next patch is there, please see,
http://winpg.jp/~saito/pg_work/OSSP_win32/
I will be adjusted and Ralf-san again.
Thanks. Yes, I wrote the wrong URL and meant this one. Is this patch
From: Tom Lane t...@sss.pgh.pa.us
Alvaro Herrera alvhe...@2ndquadrant.com writes:
At this point, I think we need to consider ossp-uuid as dead code.
Yeah, but what shall we replace it with? And can we preserve the
API contrib/uuid-ossp offers? (Maybe we shouldn't even try, but
just
Just a small patch; hopefully useful.
Best regards,
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterpriseDB Inc.
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index ccb8b86..48dc7af 100644
--- a/src/backend/postmaster/postmaster.c
+++
On Wed, Oct 30, 2013 at 12:51 PM, Sergey Konoplev gray...@gmail.com wrote:
On Wed, Oct 30, 2013 at 12:17 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
I wasn't talking about a built-in support. It was about an ability (a
way) to back sh_buf with hugepages.
Then what you need is to set
MauMau maumau...@gmail.com writes:
From: Tom Lane t...@sss.pgh.pa.us
Yeah, but what shall we replace it with? And can we preserve the
API contrib/uuid-ossp offers? (Maybe we shouldn't even try, but
just deprecate that module and start fresh.)
Would it be welcomed in this community if a
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 30, 2013 at 9:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If it *isn't* about the main memory segment, what the hell are we doing
creating random addon segments during bootstrap? None of the DSM code
should even get control at this point,
On Wed, Oct 30, 2013 at 12:12 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Andres Freund escribió:
On 2013-10-30 10:52:05 -0300, Alvaro Herrera wrote:
Robert Haas escribió:
On Wed, Oct 30, 2013 at 4:51 AM, David Rowley dgrowle...@gmail.com
wrote:
I've attached a re-based
On Wed, Oct 30, 2013 at 9:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 30, 2013 at 9:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If it *isn't* about the main memory segment, what the hell are we doing
creating random addon segments during
On Wed, Oct 16, 2013 at 1:44 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Tue, Oct 15, 2013 at 6:28 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Oct 15, 2013 at 2:55 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 14, 2013 at 1:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On Tue, Oct 29, 2013 at 12:46 PM, Naoya Anzai
anzai-na...@mxu.nes.nec.co.jp wrote:
Hi Sandeep
I think, you should change the subject line to Unquoted service path
containing space is vulnerable and can be exploited on Windows to get the
attention.. :)
Thank you for advice!
I'll try to
On Thu, Oct 31, 2013 at 10:17 AM, Amit Kapila amit.kapil...@gmail.comwrote:
On Tue, Oct 29, 2013 at 12:46 PM, Naoya Anzai
anzai-na...@mxu.nes.nec.co.jp wrote:
Hi Sandeep
I think, you should change the subject line to Unquoted service path
containing space is vulnerable and can be
68 matches
Mail list logo
