2013/8/29 Hadi Moshayedi
> Hello,
>
> > int, float, double 26829 ms (26675 ms) -- 0.5% slower .. statistic error
> ..
> > cleaner code
> > numeric sum 6490 ms (7224 ms) -- 10% faster
> > numeric avg 6487 ms (12023 ms) -- 46% faster
>
> I also got very similar results.
>
> On the other hand, init
Hello,
> int, float, double 26829 ms (26675 ms) -- 0.5% slower .. statistic error ..
> cleaner code
> numeric sum 6490 ms (7224 ms) -- 10% faster
> numeric avg 6487 ms (12023 ms) -- 46% faster
I also got very similar results.
On the other hand, initially I was receiving sigsegv's whenever I
wan
On Wed, Aug 28, 2013 at 03:16:14PM +0200, Andres Freund wrote:
> On 2013-08-27 23:46:23 -0400, Noah Misch wrote:
> > On Tue, Aug 27, 2013 at 04:14:27PM +0200, Andres Freund wrote:
> > > On 2013-06-09 17:25:59 -0400, Noah Misch wrote:
> > > > ***
> > > > *** 846,851 exec_simple_quer
On Wed, Aug 28, 2013 at 1:40 AM, Ashutosh Bapat
wrote:
> I would be good, if this set gets documented, lest users will be confused.
> Can you point me to relevant sections of document? I can add this
> documentation.
I think it's your job to look at the documentation and determine where
this woul
On 08/28/2013 09:59 PM, Robert Haas wrote:
> On Tue, Aug 27, 2013 at 6:10 PM, Pavel Stehule
> wrote:
>> what is magical?
>>
>> Stored procedures - we talk about this technology was a originally simple
>> script moved from client side to server side.
>>
>> so if I write on client side
>>
>> BEGIN;
On Wed, Aug 28, 2013 at 2:59 PM, Robert Haas wrote:
> On Tue, Aug 27, 2013 at 6:10 PM, Pavel Stehule
> wrote:
>> what is magical?
>>
>> Stored procedures - we talk about this technology was a originally simple
>> script moved from client side to server side.
>>
>> so if I write on client side
>>
On Tue, Aug 27, 2013 at 6:10 PM, Pavel Stehule wrote:
> what is magical?
>
> Stored procedures - we talk about this technology was a originally simple
> script moved from client side to server side.
>
> so if I write on client side
>
> BEGIN;
> SELECT 1,2;
> SELECT 2;
> SELECT 3,4;
> END;
>
Stephen Frost escribió:
> There are counter-examples also; sysctl.d will replace what's already
> been set, so perhaps it simply depends on an individual's experience.
> For my part, I'd much prefer an error or warning saying "you've got
> duplicate definitions of X" than a last-wins approach, tho
On Wed, Aug 28, 2013 at 03:15:14PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > Agreed, but I think this is a much larger issue than ALTER SYSTEM SET.
>
> Yeah, true.
>
> > I think changing behavior to first-seen would only add to confusion.
> > What we really need
On Tue, Aug 27, 2013 at 10:07 AM, Andres Freund wrote:
> [just sending an email which sat in my outbox for two weeks]
Thanks for taking a look.
> Nice to see this coming. I think it will actually be interesting for
> quite some things outside parallel query, but we'll see.
Yeah, I hope so. The
* Bruce Momjian (br...@momjian.us) wrote:
> Agreed, but I think this is a much larger issue than ALTER SYSTEM SET.
Yeah, true.
> I think changing behavior to first-seen would only add to confusion.
> What we really need is a WARNING when a later postgresql.conf setting
> overrides an earlier one
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > While I appreciate that there are bootstrap-type issues with this, I
> > really don't like this idea of "later stuff can just override earlier
> > stuff".
>
> > include files and conf.d-style options are for breaking the config up
On Wed, Aug 28, 2013 at 02:30:41PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Tue, Aug 27, 2013 at 09:04:00AM +0530, Amit Kapila wrote:
> > > > I really hate the idea that someone could configure 'X' in
> > > > postgresql.conf and because the auto.conf line is la
Tom,
> Does the backend's memory usage climb, or hold steady? If the former,
> I'd bet on client failure to release resources, eg not closing the
> portals when done with them. A memory map from MemoryContextStats
> would help determine exactly what's leaking.
FS cache usage increases through t
On 2013-08-28 14:04:59 -0400, Robert Haas wrote:
> >> + RegisterDynamicBackgroundWorker(BackgroundWorker
> >> + *worker, BackgroundWorkerHandle **handle). Unlike
> >> + RegisterBackgroundWorker, which can only be called from
> >> within
> >> + the postmaster, RegisterDynamicBackgroundWorker
Stephen Frost writes:
> While I appreciate that there are bootstrap-type issues with this, I
> really don't like this idea of "later stuff can just override earlier
> stuff".
> include files and conf.d-style options are for breaking the config up,
> not to allow you to override options because a
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Aug 27, 2013 at 09:04:00AM +0530, Amit Kapila wrote:
> > > I really hate the idea that someone could configure 'X' in
> > > postgresql.conf and because the auto.conf line is later in the file,
> > > it's able to override the original setting. Doe
On Wed, Aug 28, 2013 at 2:04 PM, Robert Haas wrote:
>> Hm. Not this patches fault, but We seem to allow bgw_start_time ==
>> BgWorkerStart_PostmasterStart here which doesn't make sense...
>
> I can add a check for that. I agree that it's a separate patch.
On third thought, is there really any po
On Wed, Aug 28, 2013 at 2:04 PM, Robert Haas wrote:
> I certainly can't promise that the code is bug-free. But I think it's
> probably better to get this into the tree and let people start playing
> around with it than to continue to maintain it in my private sandbox.
> At this point it's just in
On Tue, Aug 27, 2013 at 9:50 AM, Andres Freund wrote:
>> > BgwHandleStatus GetBackgroundWorkerPid(BackgroundWorkerHandle *handle,
>> > pid_t *pid);
>> > BgwHandleStatus WaitForBackgroundWorkerStartup(BackgroundWorkerHandle
>> > *handle, pid_t *pid);
>>
>> OK, here's a patch that API. I renamed
On 2013-08-28 13:31:22 -0400, Bruce Momjian wrote:
> On Sun, Aug 25, 2013 at 10:11:50PM -0400, Tom Lane wrote:
> > Michael Paquier writes:
> > > On Thu, Aug 22, 2013 at 11:55 PM, Blake Smith
> > > wrote:
> > >> The combined entry is used to support "contains (@>)" queries, and the
> > >> key
>
On Sun, Aug 25, 2013 at 10:11:50PM -0400, Tom Lane wrote:
> Michael Paquier writes:
> > On Thu, Aug 22, 2013 at 11:55 PM, Blake Smith wrote:
> >> The combined entry is used to support "contains (@>)" queries, and the key
> >> only item is used to support "key contains (?)" queries. This change se
On Mon, Aug 26, 2013 at 4:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Aug 19, 2013 at 1:41 PM, Tom Lane wrote:
>>> BTW, I notice that the MVCC-catalog-scans patch summarily asserts that
>>> RenumberEnumType no longer poses any concurrency hazards. I doubt that's
>>> true: isn't it s
Heikki Linnakangas writes:
> So, my plan is to apply the attached non-locked-tas-spin-x86_64.patch to
> master. But I would love to get feedback from people running different
> x86_64 hardware.
Surely this patch should update the existing comment at line 209? Or at
least point out that a non-l
On Tue, Aug 27, 2013 at 09:04:00AM +0530, Amit Kapila wrote:
> > For my part, I'd honestly rather have the first things found be what's
> > picked and later things be ignored. If you want it controlled by ALTER
> > SYSTEM, then don't set it in postgresql.conf. The problem with that is
> > there's
On 21.05.2013 00:20, Heikki Linnakangas wrote:
On 16.05.2013 01:08, Daniel Farina wrote:
On Mon, May 13, 2013 at 5:50 AM, Heikki Linnakangas
wrote:
pgbench -S is such a workload. With 9.3beta1, I'm seeing this
profile, when
I run "pgbench -S -c64 -j64 -T60 -M prepared" on a 32-core Linux
machi
Alvaro Herrera writes:
> "make check" in contrib/pg_upgrade should do the trick.
PASSED
Even after I added extension to the serial_schedule. I don't know if I
need to do anything specific on that area, will wait about some feedback
on that before sending a new version of the patch. Meanwhile my
Dimitri Fontaine wrote:
> Peter Eisentraut writes:
> > make -C pg_upgrade_support all
>
> Do we have something automated to easily test pg_upgrade?
"make check" in contrib/pg_upgrade should do the trick.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
Alvaro Herrera writes:
> Tom Lane wrote:
>> What exactly is the argument for pushing this into 9.3? Since we
>> are past rc1, we should treat that branch as released. If you wouldn't
>> back-patch into all supported branches, you shouldn't be patching 9.3
>> either.
> This is to fix the stats_t
I'm currently implementing commit sequence number (CSN) based
snapshots and I hit a design decision that I would like to resolve
before I have too much code to rewrite.
The issue is commit visibility ordering on slaves. As a couple of
threads on hackers have already noted, currently commit order o
Tom Lane wrote:
> What exactly is the argument for pushing this into 9.3? Since we
> are past rc1, we should treat that branch as released. If you wouldn't
> back-patch into all supported branches, you shouldn't be patching 9.3
> either.
This is to fix the stats_temp_directory issue that the di
On Tue, Aug 27, 2013 at 4:51 PM, Sawada Masahiko wrote:
> On Sun, Aug 25, 2013 at 3:21 PM, Amit Kapila wrote:
>> On Sat, Aug 24, 2013 at 2:46 PM, Sawada Masahiko
>> wrote:
>>> On Sat, Aug 24, 2013 at 3:14 AM, Josh Berkus wrote:
On 08/23/2013 12:42 AM, Sawada Masahiko wrote:
> in case
Darren Duncan writes:
> That's a really old post/thread, and I'm not arguing for any kind of action
> related to RULEs, please disregard the message. -- Darren Duncan
Oh, my fault --- for some reason my mail reader popped it up as an unread
message, and I failed to notice the date. My apologies
On 2013-08-27 23:46:23 -0400, Noah Misch wrote:
> On Tue, Aug 27, 2013 at 04:14:27PM +0200, Andres Freund wrote:
> > On 2013-06-09 17:25:59 -0400, Noah Misch wrote:
> > > ***
> > > *** 846,851 exec_simple_query(const char *query_string)
> > > --- 847,856
> > >
> > >
On 2013-08-28 13:58:08 +0900, Michael Paquier wrote:
> On Tue, Aug 27, 2013 at 11:09 PM, Andres Freund
> wrote:
> > On 2013-08-27 15:34:22 +0900, Michael Paquier wrote:
> >> I have been working a little bit more on this patch for the next
> >> commit fest. Compared to the previous version, I have
2013/8/28 Oleg Bartunov :
> btw, there is serious problem with row-level security and constraints. For
> example, user with low security level could use unique constraint to know
> about existence of a row with higher security. I don't know, what is the
> best practice to avoid this.
>
It is out o
Peter Eisentraut writes:
> make -C pg_upgrade_support all
Do we have something automated to easily test pg_upgrade?
My memories of how pg_upgrade works with extensions makes me believe
that I don't have anything special to do when those extensions have been
made available through a template: the
37 matches
Mail list logo
