On 17.11.2010 03:56, Robert Haas wrote:
On Tue, Nov 16, 2010 at 7:46 PM, Tom Lane wrote:
Robert Haas writes:
On Tue, Nov 16, 2010 at 5:57 PM, marcin mank wrote:
Can (should ?) unlogged tables' contents survive graceful (non-crash) shutdown?
I don't think so. To make that work, you'd nee
I revised my patch as I attached.
The hook function is modified and consolidated as follows:
typedef enum FunctionCallEventType
{
FCET_BE_HOOKED,
FCET_PREPARE,
FCET_START,
FCET_END,
FCET_ABORT,
} FunctionCallEventType;
typedef Datum (*function_call_event_type)(Oi
On Wed, Nov 17, 2010 at 10:51, Itagaki Takahiro
wrote:
> On Wed, Nov 17, 2010 at 03:36, Robert Haas wrote:
>> On Tue, Nov 16, 2010 at 1:28 PM, Tom Lane wrote:
>>> I am of the opinion that a run-time-extensible set of plan node types
>>> is merest fantasy. We will never have that, so putting in
Chris Forno writes:
> I'd like to add information about whether or not a parameter or result can
> potentially be NULL to the RowDescription message.
There is noplace to put that without a FE/BE protocol break; and it's
not worth it by itself. This is one of a number of things that we'll
probabl
I'd like to add information about whether or not a parameter or result can
potentially be NULL to the RowDescription message.
Reason: I have the same reasons that Richard Jones did in 2006 (
http://archives.postgresql.org/pgsql-interfaces/2006-01/msg00043.php). I'm
writing a Haskell library that d
2010/11/16 Tom Lane :
> Martijn van Oosterhout writes:
>> On Tue, Nov 16, 2010 at 10:32:01PM +0200, Peter Eisentraut wrote:
>>> On tis, 2010-11-16 at 21:05 +0100, marcin mank wrote:
It would be nice if we could have some mapping of locale names bult
in, so one doesn`t have to write alter
On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Kohei wrote:
> If we don't need a PoC module for each new hooks, I'm not strongly
> motivated to push it into contrib tree.
> How about your opinion?
I'd say let it go, unless someone else feels strongly about it.
> Sorry, I missed the manner of contrib mo
Thanks for the additional information!
On Tue, 16 Nov 2010 09:31:43 -0800
Eric Davies wrote:
> At 01:36 AM 11/16/2010, Shigeru HANADA wrote:
> >On Mon, 15 Nov 2010 08:45:14 -0800
> >Eric Davies wrote:
> >ISTM that index on a VTI table could be inconsistent when original
> >(remote) data was chan
On Tue, Nov 16, 2010 at 02:07:35PM -0800, David Fetter wrote:
> On Tue, Nov 16, 2010 at 02:00:33PM -0800, Josh Berkus wrote:
> > > Yeah, you'd have to allow a flag to control the behavior. And in
> > > that case I'd rather the flag have a single default rather than
> > > different defaults dependi
On Tue, Nov 16, 2010 at 7:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Nov 16, 2010 at 5:57 PM, marcin mank wrote:
>>> Can (should ?) unlogged tables' contents survive graceful (non-crash)
>>> shutdown?
>
>> I don't think so. To make that work, you'd need to keep track of
>> every b
On Wed, Nov 17, 2010 at 03:36, Robert Haas wrote:
> On Tue, Nov 16, 2010 at 1:28 PM, Tom Lane wrote:
>> I am of the opinion that a run-time-extensible set of plan node types
>> is merest fantasy. We will never have that, so putting in place 5%
>> of the infrastructure for it is a waste of time a
(2010/11/15 11:50), Robert Haas wrote:
On Thu, Nov 4, 2010 at 10:04 AM, Robert Haas wrote:
On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost wrote:
* Jan Urbański (wulc...@wulczer.org) wrote:
On 04/11/10 14:09, Robert Haas wrote:
Hmm, I wonder how useful this is given that restriction.
As Kai
On 11/16/10 4:40 PM, Robert Haas wrote:
> But I'm happy to leave all of this until we gain some field experience
> with this feature, and have a better idea what features people would
> most like to see.
+1. Let's not complicate this.
--
-- Josh Berkus
Robert Haas writes:
> On Tue, Nov 16, 2010 at 5:57 PM, marcin mank wrote:
>> Can (should ?) unlogged tables' contents survive graceful (non-crash)
>> shutdown?
> I don't think so. To make that work, you'd need to keep track of
> every backing file that might contain pages not fsync()'d to disk
On Tue, Nov 16, 2010 at 5:57 PM, marcin mank wrote:
> Can (should ?) unlogged tables' contents survive graceful (non-crash)
> shutdown?
I don't think so. To make that work, you'd need to keep track of
every backing file that might contain pages not fsync()'d to disk, and
at shutdown time you'd
Can (should ?) unlogged tables' contents survive graceful (non-crash) shutdown?
Greetings
Marcin Mańk
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Nov 16, 2010 at 5:30 PM, Andres Freund wrote:
> On Tuesday 16 November 2010 23:12:10 Josh Berkus wrote:
>> On 11/16/10 2:08 PM, Peter Eisentraut wrote:
>> > On tis, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
>> >> It seems to me
>> >> that most people using unlogged tables won't want to
Peter Eisentraut writes:
> On fre, 2010-11-12 at 09:44 -0500, Tom Lane wrote:
>> But I'm still not convinced that this feature is useful enough to
>> justify the implementation effort. AFAICS there's nothing here that
>> you couldn't get with some non-default operators on regular arrays,
> Uniqu
> That's a very debatable assumption. You got any evidence for it?
> Personally, I don't think pg_dump should ever default to omitting
> data.
Survey launched, although it may become a moot point, given how this
discussion is going.
--
-- Josh Berkus
Josh Berkus writes:
>> Yeah, you'd have to allow a flag to control the behavior. And in that
>> case I'd rather the flag have a single default rather than different
>> defaults depending on whether or not individual tables were selected.
>> Something like --omit-unlogged-data.
> Are you sure we
On Tuesday 16 November 2010 23:30:29 Andres Freund wrote:
> On Tuesday 16 November 2010 23:12:10 Josh Berkus wrote:
> > On 11/16/10 2:08 PM, Peter Eisentraut wrote:
> > > On tis, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
> > >> It seems to me
> > >> that most people using unlogged tables won't
Martijn van Oosterhout writes:
> On Tue, Nov 16, 2010 at 10:32:01PM +0200, Peter Eisentraut wrote:
>> On tis, 2010-11-16 at 21:05 +0100, marcin mank wrote:
>>> It would be nice if we could have some mapping of locale names bult
>>> in, so one doesn`t have to write alternative sql depending on DB
>
Andres Freund wrote:
> One way your backup runs too long and too much data changes, the
> other way round you loose the data which you assumed safely
> backuped.
>
> Isn't that a *really* easy decision?
Yeah. Count me in the camp which wants the default behavior to be
that pg_dump backs up a
On Tuesday 16 November 2010 23:12:10 Josh Berkus wrote:
> On 11/16/10 2:08 PM, Peter Eisentraut wrote:
> > On tis, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
> >> It seems to me
> >> that most people using unlogged tables won't want to back them up ...
> >> especially since the share lock for pg
Peter Eisentraut writes:
> On mån, 2010-11-15 at 23:34 -0500, Tom Lane wrote:
>> It's clear to me that we are very far from having a handle on what
>> it'll really take to run parallel builds safely, and I am therefore
>> now of the opinion that we ought to revert the patch.
> We don't have to r
Jignesh Shah wrote:
> The question is should the delete fail if it doesn't exist and
> cause a rollback or succeed with DELETE 0 ?
I think existing behavior is consistent with both the standard and
the other behaviors of PostgreSQL at the READ COMMITTED isolation
level. I might have found it
On Wed, 2010-11-17 at 00:08 +0200, Peter Eisentraut wrote:
> On tis, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
> > It seems to me
> > that most people using unlogged tables won't want to back them up ...
> > especially since the share lock for pgdump will add overhead for the
> > kinds of high-
Robert Haas writes:
> On Tue, Nov 16, 2010 at 3:50 PM, Tom Lane wrote:
>> I think allowing pg_dump to dump the data in an unlogged table is not
>> only reasonable, but essential.
> Yeah, you'd have to allow a flag to control the behavior. And in that
> case I'd rather the flag have a single def
On 11/16/2010 05:12 PM, Josh Berkus wrote:
On 11/16/10 2:08 PM, Peter Eisentraut wrote:
On tis, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
It seems to me
that most people using unlogged tables won't want to back them up ...
especially since the share lock for pgdump will add overhead for t
On fre, 2010-11-12 at 09:44 -0500, Tom Lane wrote:
> But I'm still not convinced that this feature is useful enough to
> justify the implementation effort. AFAICS there's nothing here that
> you couldn't get with some non-default operators on regular arrays,
Unique constraints would behave differ
On Tue, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
> > Yeah, you'd have to allow a flag to control the behavior. And in that
> > case I'd rather the flag have a single default rather than different
> > defaults depending on whether or not individual tables were selected.
> > Something like --om
On 11/16/10 2:08 PM, Peter Eisentraut wrote:
> On tis, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
>> It seems to me
>> that most people using unlogged tables won't want to back them up ...
>> especially since the share lock for pgdump will add overhead for the
>> kinds of high-volume updates peo
On tis, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
> It seems to me
> that most people using unlogged tables won't want to back them up ...
> especially since the share lock for pgdump will add overhead for the
> kinds of high-volume updates people want to do with unlogged tables.
Or perhaps mo
On Tue, Nov 16, 2010 at 02:00:33PM -0800, Josh Berkus wrote:
> > Yeah, you'd have to allow a flag to control the behavior. And in
> > that case I'd rather the flag have a single default rather than
> > different defaults depending on whether or not individual tables
> > were selected. Something l
> Yeah, you'd have to allow a flag to control the behavior. And in that
> case I'd rather the flag have a single default rather than different
> defaults depending on whether or not individual tables were selected.
> Something like --omit-unlogged-data.
Are you sure we don't want to default the
On Tue, Nov 16, 2010 at 3:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Nov 16, 2010 at 1:58 PM, Alvaro Herrera
>>> I think if you do a regular backup of the complete database, unlogged
>>> tables should come out empty, but if you specifically request a dump of
>>> it, it shouldn't.
>
>
On mån, 2010-11-15 at 23:34 -0500, Tom Lane wrote:
> It's clear to me that we are very far from having a handle on what
> it'll really take to run parallel builds safely, and I am therefore
> now of the opinion that we ought to revert the patch. Hypothetical
> gains in parallelism are useless if w
On tis, 2010-11-16 at 16:04 -0500, Tom Lane wrote:
> Well, my expectation would be that the committer would reset the
> catversion to current date when it goes into master. The question is
> whether such a practice would be (a) helpful to testers and/or (b)
> useful to the committer.
As with most
On 11/16/2010 02:06 PM, Robert Haas wrote:
On Tue, Nov 16, 2010 at 1:58 PM, Alvaro Herrera
wrote:
I think if you do a regular backup of the complete database, unlogged
tables should come out empty, but if you specifically request a dump of
it, it shouldn't.
Oh, wow. That seems confusing.
On Tue, Nov 16, 2010 at 10:32:01PM +0200, Peter Eisentraut wrote:
> On tis, 2010-11-16 at 21:05 +0100, marcin mank wrote:
> > It would be nice if we could have some mapping of locale names bult
> > in, so one doesn`t have to write alternative sql depending on DB
> > server OS:
> > select * from tab
Robert Haas writes:
> On Tue, Nov 16, 2010 at 2:49 PM, Peter Eisentraut wrote:
>> Btw., I would recommend that even in-progress or proposed patches
>> include catversion updates,
> I thought we had a policy of NOT doing that, because of the merge
> conflicts thereby created. It's also hard to k
On tis, 2010-11-16 at 21:40 +0100, Pavel Stehule wrote:
> ok, then we should to define this alias manually
>
> some like - CREATE COLLATE "czech" FOR LOCALE "cs_CZ.UTF8"
>
> or some similar. Without this, the application or stored procedures
> can be non portable between UNIX and WIN.
Yes, such
On Tue, Nov 16, 2010 at 3:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> Oh. So do the indexes just degrade over time until they eventually
>> need to be REINDEX'd?
>
> At some point you might reach a state where a reindex would be helpful.
> But the same is true of btrees. I don't think this
On 16.11.2010 21:20, Teodor Sigaev wrote:
they are consistent with the new key we're inserting. The old GiST
algorithm adjusted all the parent pages only after inserting the tuple
on the leaf. Updating them on the way down ensures that the tree is
Hm, performance? while you traverse to leaf page
Robert Haas writes:
> On Tue, Nov 16, 2010 at 1:58 PM, Alvaro Herrera
>> I think if you do a regular backup of the complete database, unlogged
>> tables should come out empty, but if you specifically request a dump of
>> it, it shouldn't.
> Oh, wow. That seems confusing.
I don't like it either.
Robert Haas writes:
> Oh. So do the indexes just degrade over time until they eventually
> need to be REINDEX'd?
At some point you might reach a state where a reindex would be helpful.
But the same is true of btrees. I don't think this is a serious
objection, at least not unless backed by evide
2010/11/16 Peter Eisentraut :
> On tis, 2010-11-16 at 20:59 +0100, Pavel Stehule wrote:
>> 2010/11/16 Peter Eisentraut :
>> > On tis, 2010-11-16 at 20:00 +0100, Pavel Stehule wrote:
>> >> yes - my first question is: Why we need to specify encoding, when only
>> >> one encoding is supported? I can't
>> Relevant to this is the question: *when* does vacuum do its memory
>> allocation? Is memory allocation reasonably front-loaded, or does
>> vacuum keep grabbing more RAM until it's done?
>
> All at start.
That means that "allocation by halves" would work fine.
--
On tis, 2010-11-16 at 21:05 +0100, marcin mank wrote:
> It would be nice if we could have some mapping of locale names bult
> in, so one doesn`t have to write alternative sql depending on DB
> server OS:
> select * from tab order by foo collate "Polish, Poland"
> select * from tab order by foo coll
On tis, 2010-11-16 at 20:59 +0100, Pavel Stehule wrote:
> 2010/11/16 Peter Eisentraut :
> > On tis, 2010-11-16 at 20:00 +0100, Pavel Stehule wrote:
> >> yes - my first question is: Why we need to specify encoding, when only
> >> one encoding is supported? I can't to use a cs_CZ.iso88592 when my db
On tis, 2010-11-16 at 15:08 -0500, Robert Haas wrote:
> > Btw., I would recommend that even in-progress or proposed patches
> > include catversion updates, which helps communicate the message such
> as
> > yours in a more robust manner and also reduces the chance of
> forgetting
> > the catversion
2010/11/16 marcin mank :
>> I can only look at the locales that the operating system provides. We
>> could conceivably make some simplifications like stripping off the
>> ".utf8", but then how far do we go and where do we stop? Locale names
>> on Windows look different too. But in general, how d
On Tue, Nov 16, 2010 at 2:49 PM, Peter Eisentraut wrote:
> On lör, 2010-11-13 at 19:16 -0500, Robert Haas wrote:
>> 1. The first one (relpersistence-v1) is a mostly mechanical patch that
>> replaces pg_class.relistemp (a Boolean) with pg_class.relpersistence
>> (a character), so that we can suppor
Actually cutting down my mail to something more readable..
Lets consider two transactions
BEGIN;
BEGIN;
DELETE FROM sbtest WHERE id=500815;
INSERT INTO sbtest
values(500815,0,'','aaffrreeyy');
DELETE FROM sbtest WHERE id=500815;
On Tue, Nov 16, 2010 at 2:53 PM, Greg Stark wrote:
>> Yeah, VERBOSE is kind of a catch-all for things that we don't have
>> individual flags for. But I think it's better for each piece of data
>> to depend on one setting, rather than a combination of two or more
>> settings. Otherwise you end up
> I can only look at the locales that the operating system provides. We
> could conceivably make some simplifications like stripping off the
> ".utf8", but then how far do we go and where do we stop? Locale names
> on Windows look different too. But in general, how do you suppose we
> should map
2010/11/16 Peter Eisentraut :
> On tis, 2010-11-16 at 20:00 +0100, Pavel Stehule wrote:
>> yes - my first question is: Why we need to specify encoding, when only
>> one encoding is supported? I can't to use a cs_CZ.iso88592 when my db
>> use a UTF8 - btw there is wrong message:
>>
>> yyy=# select *
On Tue, Nov 16, 2010 at 11:38 AM, Robert Haas wrote:
>> I think we should have a project policy of always printing memory and
>> disk usage in kB, MB, GB etc unless they're functions returning an
>> integer intended for machine use.
>
> rhaas=# set work_mem to '1048577kB';
Interesting. Though in
2010/11/16 Magnus Hagander :
> On Tue, Nov 16, 2010 at 16:09, Tom Lane wrote:
>> Magnus Hagander writes:
>>> Is there a particular reason why track_functions is disabled by default?
>>
>> Performance worries, plus the thought that not everyone cares to
>> have these stats.
>
> Most people who are
Hello All,
I am recently using sysbench with PostgreSQL 9.0 and 8.4.5 and doing
some tests on 8core systems with SSDs.
I seem to be hitting some problems with the read-write tests and
hoping to see if it is a possible concurrency bug or expected
behavior.
Using sysbench with 1M rows and 80+ t
On lör, 2010-11-13 at 19:16 -0500, Robert Haas wrote:
> 1. The first one (relpersistence-v1) is a mostly mechanical patch that
> replaces pg_class.relistemp (a Boolean) with pg_class.relpersistence
> (a character), so that we can support more than two values. BE SURE
> YOU INITDB, since the old ca
On Tue, Nov 16, 2010 at 12:19 PM, Greg Stark wrote:
> On Tue, Nov 16, 2010 at 2:43 AM, Robert Haas wrote:
>> I don't really think these changes to the INSTR macros make much
>> sense. The macros don't really add much notational convenience;
>> they're mostly wrappers to make the WIN32 and non-WI
On tis, 2010-11-16 at 20:00 +0100, Pavel Stehule wrote:
> yes - my first question is: Why we need to specify encoding, when only
> one encoding is supported? I can't to use a cs_CZ.iso88592 when my db
> use a UTF8 - btw there is wrong message:
>
> yyy=# select * from jmena order by jmeno collate "
they are consistent with the new key we're inserting. The old GiST
algorithm adjusted all the parent pages only after inserting the tuple
on the leaf. Updating them on the way down ensures that the tree is
Hm, performance? while you traverse to leaf page, on each inner page you will
need to call
On Tue, Nov 16, 2010 at 1:50 PM, Heikki Linnakangas
wrote:
>> If we start to enlarge the bounding boxes on the higher levels of the
>> tree and then crash before inserting the key, is there any mechanism
>> for getting them back down to the minimal size?
>
> No. There's also no mechanism for trimm
On Tue, Nov 16, 2010 at 1:58 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mar nov 16 15:34:55 -0300 2010:
>> On Tue, Nov 16, 2010 at 1:09 PM, Andy Colson wrote:
>
>> > dump/restore?
>>
>> All of those. I guess there's a question of what pg_dump should emit
>> for an unlogge
Excerpts from Josh Berkus's message of mar nov 16 15:52:14 -0300 2010:
>
> > I think the difficulty is figuring out what to get the existing
> > workers to give us some memory when a new one comes along. You want
> > the first worker to potentially use ALL the memory... until worker #2
> > arrive
Hello
2010/11/16 Peter Eisentraut :
> On mån, 2010-11-15 at 23:13 +0100, Pavel Stehule wrote:
>> a) default encoding for collate isn't same as default encoding of database
>>
>> it's minimally not friendly - mostly used encoding is UTF8, but in
>> most cases users should to write locale.utf8.
>
>
Excerpts from Robert Haas's message of mar nov 16 15:34:55 -0300 2010:
> On Tue, Nov 16, 2010 at 1:09 PM, Andy Colson wrote:
> > dump/restore?
>
> All of those. I guess there's a question of what pg_dump should emit
> for an unlogged table. Clearly, we need to dump a CREATE UNLOGGED
> TABLE st
> I think the difficulty is figuring out what to get the existing
> workers to give us some memory when a new one comes along. You want
> the first worker to potentially use ALL the memory... until worker #2
> arrives.
Yeah, doing this would mean that you couldn't give worker #1 all the
memory,
On 16.11.2010 20:46, Robert Haas wrote:
On Tue, Nov 16, 2010 at 1:22 PM, Heikki Linnakangas
wrote:
BTW, I don't try to fix incomplete splits during vacuum in the patch. That's
perhaps a bit surprising, and probably would be easy to add, but I left it
out for now as it's not strictly necessary.
On Tue, Nov 16, 2010 at 1:22 PM, Heikki Linnakangas
wrote:
> BTW, I don't try to fix incomplete splits during vacuum in the patch. That's
> perhaps a bit surprising, and probably would be easy to add, but I left it
> out for now as it's not strictly necessary.
Seems like it would be good to have
On Tue, 2010-11-16 at 10:36 -0800, Josh Berkus wrote:
> On 11/16/10 9:27 AM, Robert Haas wrote:
> > I'm a little skeptical about creating more memory tunables. DBAs who
> > are used to previous versions of PG will find that their vacuum is now
> > really slow, because they adjusted maintenance_wor
On Tue, Nov 16, 2010 at 1:36 PM, Josh Berkus wrote:
> On 11/16/10 9:27 AM, Robert Haas wrote:
>> I'm a little skeptical about creating more memory tunables. DBAs who
>> are used to previous versions of PG will find that their vacuum is now
>> really slow, because they adjusted maintenance_work_me
On 11/16/10 9:27 AM, Robert Haas wrote:
> I'm a little skeptical about creating more memory tunables. DBAs who
> are used to previous versions of PG will find that their vacuum is now
> really slow, because they adjusted maintenance_work_mem but not this
Also, generally people who are using autov
On Tue, Nov 16, 2010 at 1:28 PM, Tom Lane wrote:
> Itagaki Takahiro writes:
>> Here is a WIP patch to extensible executor nodes.
>
> I am of the opinion that a run-time-extensible set of plan node types
> is merest fantasy. We will never have that, so putting in place 5%
> of the infrastructure
On Tue, Nov 16, 2010 at 1:09 PM, Andy Colson wrote:
> I was able to apply and compile and run ok, creating unlogged tables seems
> to work as well.
>
> I patched up pgbench to optionally create unlogged tables, and ran it both
> ways. I get ~80tps normally, and ~1,500tps with unlogged. (Thats fr
Itagaki Takahiro writes:
> Here is a WIP patch to extensible executor nodes.
I am of the opinion that a run-time-extensible set of plan node types
is merest fantasy. We will never have that, so putting in place 5%
of the infrastructure for it is a waste of time and notational
complexity.
I woul
On 16.11.2010 20:01, Tom Lane wrote:
Heikki Linnakangas writes:
2. When a page is split, we mark the new left page with a flag to
indicate that the downlink for the page to the right hasn't been
inserted yet. When the downlink is inserted, the flag is cleared. Again
the purpose is to ensure tha
Andy Colson writes:
> Is "create temp unlogged table stuff(...)" an option?
temp tables are unlogged already.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
"Greg Sabino Mullane" writes:
> Tom asked:
>> What happens to plperl?
> It still doesn't work. I was going to leave it out via --without-perl,
> and save fixing that for another day. There's a handful of other
> warnings when making, but --with-perl is the only showstopper
> (once the GNU_SOUR
I was able to apply and compile and run ok, creating unlogged tables
seems to work as well.
I patched up pgbench to optionally create unlogged tables, and ran it
both ways. I get ~80tps normally, and ~1,500tps with unlogged. (Thats
from memory, was playing with it last night at home)
I als
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom asked:
> What happens to plperl?
It still doesn't work. I was going to leave it out via --without-perl,
and save fixing that for another day. There's a handful of other
warnings when making, but --with-perl is the only showstopper
(once
Heikki Linnakangas writes:
> There are two key changes to the insert algorithm:
> 1. When we walk down the tree searching for a suitable leaf page to
> insert the new tuple to, we update the nodes on the way down so that
> they are consistent with the new key we're inserting. The old GiST
> al
At 01:36 AM 11/16/2010, Shigeru HANADA wrote:
Thanks for the information about Informix VTI. Because I'm not
familiar to Informix, I might have missed your point. Would you mind
telling me more about Informix VTI?
On Mon, 15 Nov 2010 08:45:14 -0800
Eric Davies wrote:
> With Informix VTI, i
On Tue, Nov 16, 2010 at 11:12 AM, Alvaro Herrera
wrote:
> Magnus was just talking to me about having a better way of controlling
> memory usage on autovacuum. Instead of each worker using up to
> maintenance_work_mem, which ends up as a disaster when DBA A sets to a
> large value and DBA B raises
On 16.11.2010 18:12, Alvaro Herrera wrote:
Thoughts?
Sounds reasonable, but you know what would be even better? Use less
memory in vacuum, so that it doesn't become an issue to begin with.
There was some discussion on that back in 2007
(http://archives.postgresql.org/pgsql-hackers/2007-02/ms
On Tue, Nov 16, 2010 at 2:43 AM, Robert Haas wrote:
> I don't really think these changes to the INSTR macros make much
> sense. The macros don't really add much notational convenience;
> they're mostly wrappers to make the WIN32 and non-WIN32 cases work
> similarly for the instrumentation stuff,
Itagaki Takahiro writes:
> On Wed, Nov 17, 2010 at 01:12, Alvaro Herrera wrote:
>> So for the initial implementation, we could just have each worker set
>> its local maintenance_work_mem to autovacuum_maintenance_memory /
>> max_workers.
>> That way there's never excessive memory usage.
> It so
On mån, 2010-11-15 at 23:13 +0100, Pavel Stehule wrote:
> a) default encoding for collate isn't same as default encoding of database
>
> it's minimally not friendly - mostly used encoding is UTF8, but in
> most cases users should to write locale.utf8.
I don't understand what you are trying to say
On Wed, Nov 17, 2010 at 01:12, Alvaro Herrera wrote:
> So for the initial implementation, we could just have each worker set
> its local maintenance_work_mem to autovacuum_maintenance_memory / max_workers.
> That way there's never excessive memory usage.
It sounds reasonable, but is there the sam
On tis, 2010-11-16 at 09:41 -0500, Greg Sabino Mullane wrote:
> I've been trying to get clang working enough that I can at
> least get HEAD going for a build farm client, and the attached
> patch is the bare minimum to get it working. There may be a
> better way to do this, but as indicated in a
Magnus was just talking to me about having a better way of controlling
memory usage on autovacuum. Instead of each worker using up to
maintenance_work_mem, which ends up as a disaster when DBA A sets to a
large value and DBA B raises autovacuum_max_workers, we could simply
have an "autovacuum_main
On 13.11.2010 00:34, Greg Stark wrote:
On Fri, Nov 12, 2010 at 7:20 PM, Heikki Linnakangas
wrote:
I think we can work around that with a small modification to the page split
algorithm. In a nutshell, when the child page is split, put a flag on the
left half indicating that the rightlink must a
On Tue, Nov 16, 2010 at 16:35, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Nov 16, 2010 at 16:23, Tom Lane wrote:
>>> What's not clear to me is whether the section title means that only
>>> certain handles have this guarantee, and if so whether we have to worry
>>> about running into on
On Tue, Nov 16, 2010 at 16:23, Tom Lane wrote:
> Magnus Hagander writes:
>> Do you still have a reference to the page that said they will never be
>> assigned that high?
>
> http://msdn.microsoft.com/en-us/library/ms810720.aspx
>
> which says
>
> USER and GDI handles are sign extended 32b valu
On Tue, Nov 16, 2010 at 16:09, Tom Lane wrote:
> Magnus Hagander writes:
>> Is there a particular reason why track_functions is disabled by default?
>
> Performance worries, plus the thought that not everyone cares to
> have these stats.
Most people who are actively using stored procedures proba
Greg Sabino Mullane writes:
> I've been trying to get clang working enough that I can at
> least get HEAD going for a build farm client, and the attached
> patch is the bare minimum to get it working. There may be a
> better way to do this, but as indicated in a past thread, the
> GNU_SOURCE v
On Tue, Nov 16, 2010 at 15:42, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Nov 16, 2010 at 11:01, Magnus Hagander wrote:
>>> So yes, it looks completely broken. I guess Windows doesn't actually
>>> *assign* you a handle larger than 2^32 until you actually ahve that
>>> many open handles
I've been trying to get clang working enough that I can at
least get HEAD going for a build farm client, and the attached
patch is the bare minimum to get it working. There may be a
better way to do this, but as indicated in a past thread, the
GNU_SOURCE variable does not play nicely with clang
1 - 100 of 109 matches
Mail list logo
