On Wed, Jun 1, 2011 at 6:35 PM, Mark Kirkwood
wrote:
> On 01/06/11 09:24, Cédric Villemain wrote:
>>
>> Submission review
>>
>>
>> * The patch is not in context diff format.
>> * The patch apply, but contains some extra whitespace.
>> * Documentation is here but not e
Hello
I am playing with context callback functions. I found so we leave
early this function, when exception is raised by RAISE statement.
I can understand it when level is NOTICE, but it is strange for other
levels. More we can emulate any exception now, but these exceptions
are hidden in context
2011/6/1 Alexander Korotkov
> 2011/6/1 Teodor Sigaev
>>
>> One of idea is add sorting of Datums to be splitted by cost of insertion.
>> It's implemented in intarray/tsearch GiST indexes.
>>
>
> Yes, it's a good compromise between linear and quadratic entries
> distribution algorithms. In quadrat
On Wed, Jun 01, 2011 at 10:26:34PM -0400, Josh Kupershmidt wrote:
> On Wed, Jun 1, 2011 at 5:55 PM, Noah Misch wrote:
> > On Sun, May 29, 2011 at 10:56:02AM -0400, Josh Kupershmidt wrote:
> >> Looking around, I see there were real problems[1] with sending SIGTERM
> >> to individual backends back i
On 02/06/11 11:35, Mark Kirkwood wrote:
On 01/06/11 09:24, Cédric Villemain wrote: Simple Feature test
==
either explain buffers is wrong or the patch is wrong:
cedric=# explain (analyze,buffers) select * from foo order by 1 desc ;
On Wed, Jun 1, 2011 at 5:55 PM, Noah Misch wrote:
> On Sun, May 29, 2011 at 10:56:02AM -0400, Josh Kupershmidt wrote:
>> Looking around, I see there were real problems[1] with sending SIGTERM
>> to individual backends back in 2005 or so, and pg_terminate_backend()
>> was only deemed safe enough to
On Wed, Jun 1, 2011 at 8:18 PM, Alvaro Herrera
wrote:
> Excerpts from Jeff Davis's message of mié jun 01 19:57:40 -0400 2011:
>> On Fri, 2011-05-27 at 16:43 -0400, Alvaro Herrera wrote:
>> > Hi,
>> >
>> > One of our customers is interested in being able to store original
>> > timezone along with a
Excerpts from Thom Brown's message of mié jun 01 19:48:44 -0400 2011:
> Is this expected?
> [ pg_dump fails to preserve not-valid status of constraints ]
Certainly not.
> Shouldn't the constraint be dumped as not valid too??
Sure, I'll implement that tomorrow.
--
Álvaro Herrera
The PostgreSQ
On Fri, 2011-05-27 at 16:43 -0400, Alvaro Herrera wrote:
> Hi,
>
> One of our customers is interested in being able to store original
> timezone along with a certain timestamp.
I assume that you're talking about a new data type, not augmenting the
current types, correct?
Regards,
Jeff Da
Excerpts from Jeff Davis's message of mié jun 01 19:57:40 -0400 2011:
> On Fri, 2011-05-27 at 16:43 -0400, Alvaro Herrera wrote:
> > Hi,
> >
> > One of our customers is interested in being able to store original
> > timezone along with a certain timestamp.
>
> I assume that you're talking about a
I wrote:
> Please note also that what pgpool users have got right now is a time
> bomb, which is not better than immediately-visible breakage.
BTW, so far as that goes, I suggest that we tweak nextval() and setval()
to force the sequence tuple's xmax to zero. That will provide a simple
recovery p
Alvaro Herrera writes:
> Excerpts from Tatsuo Ishii's message of mié jun 01 19:08:16 -0400 2011:
>> What pgpool really wanted to do was locking sequence tables, not
>> locking rows in sequences. I wonder why the former is not allowed.
> Yeah -- why is LOCK SEQUENCE foo_seq not allowed? Seems a
>> Yeah -- why is LOCK SEQUENCE foo_seq not allowed? Seems a simple thing
>> to have.
>
> I don't see any particular reason to continue to disallow it, but does
> that actually represent a workable solution path for pgpool? Switching
> over to that would fail on older servers.
pgpool will provi
On 1 June 2011 23:47, Alvaro Herrera wrote:
>
> Here's a complete patch with all this stuff, plus doc additions and
> simple regression tests for the new ALTER DOMAIN commands.
>
> Enable CHECK constraints to be declared NOT VALID
>
> This means that they can initially be added to a large ex
Excerpts from Tatsuo Ishii's message of mié jun 01 19:08:16 -0400 2011:
> What pgpool really wanted to do was locking sequence tables, not
> locking rows in sequences. I wonder why the former is not allowed.
Yeah -- why is LOCK SEQUENCE foo_seq not allowed? Seems a simple thing
to have.
--
Álv
On 01/06/11 09:24, Cédric Villemain wrote:
Submission review
* The patch is not in context diff format.
* The patch apply, but contains some extra whitespace.
* Documentation is here but not explicit about 'temp tables',
maybe worth adding that this won't limit
On Jun2, 2011, at 00:02 , Noah Misch wrote:
> On Wed, Jun 01, 2011 at 06:16:21PM +0200, Florian Pflug wrote:
>> Anyway, I'll try to come up with a patch that replaces
>> xmlSetGenericErrorFunc() with xmlSetStructuredErrorFunc().
>
> Sounds sensible. Will this impose any new libxml2 version depen
> Maybe. How hard would it be to fix that so it doesn't blow up? What
> I don't like about the proposed solution is that it will cause very
> user-visible breakage as a result of a minor release upgrade, for
> anyone using pgpool, which is a lot of people; unless pgpool is
> upgraded to a suffici
> If we're going to try to retroactively make the world safe for pgpool
> doing what it's doing, the only way is to start including sequences in
> the set of objects that are vacuumed and included in
> relfrozenxid/datfrozenxid bookkeeping. Which is a lot more overhead
> than I think is justified
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of mié jun 01 18:22:56 -0400 2011:
>> ISTM that it would be useful to run postgres in a mode where it
>> doesn't actually try to start up the database, but parses
>> postgresql.conf and then exits, perhaps printing out the value of a
>>
Excerpts from Robert Haas's message of mié jun 01 18:22:56 -0400 2011:
> ISTM that it would be useful to run postgres in a mode where it
> doesn't actually try to start up the database, but parses
> postgresql.conf and then exits, perhaps printing out the value of a
> certain GUC as it does so. I
Robert Haas writes:
> On Wed, Jun 1, 2011 at 6:04 PM, Tom Lane wrote:
>> * Does anyone want to argue for not forbidding SELECT FOR UPDATE on
>> toast tables?
> Maybe. How hard would it be to fix that so it doesn't blow up? What
> I don't like about the proposed solution is that it will cause v
I'd like to thank you all for getting this analyzed, especially Tom!
Your rigor is pretty impressive. Seems like otherwise it'd impossible to
maintain a DBS, though.
In the end, I know a lot more of postgres internals and that this
idiosyncrasy (from a user perspective) could happen again. I guess
Teodor Sigaev writes:
> I found problem while vacuuming with composite type (version 9.0.4). It's not
> so
> easy to reproduce, but it's clear what happens.
> CREATE TYPE mytype AS (p point, r float8);
> CREATE TABLE mytable (mt mytype);
> -- create opclass fir GiST
> CREATE INDEX myidx ON myta
On Wed, Jun 1, 2011 at 6:04 PM, Tom Lane wrote:
> I wrote:
> I think the most appropriate solution may be to disallow SELECT FOR
> UPDATE/SHARE on sequences ... so if you have a good reason why we
> shouldn't do so, please explain it.
>
> Attached is a proposed patch to close off this
> No, it isn't. You're making way too many assumptions about where things
> really were and what arguments were given to pg_ctl start. We went
> around on this before, which is why it's not "fixed" already.
What should I search on? I can't find the relevant discussion.
--
Josh Berkus
Postgre
On Wed, Jun 1, 2011 at 5:10 PM, Tom Lane wrote:
> Josh Berkus writes:
>> pg_ctl -D means different things depending on whether you are calling
>> "start" or "stop". For "start", pg_ctl wants the directory
>> postgresql.conf is in, and for "stop" it wants the directory
>> postmaster.pid is in. T
Heikki Linnakangas wrote:
> On 30.05.2011 17:10, Kevin Grittner wrote:
>> This optimization is an original one, not yet appearing in any
>> academic papers; Dan and I are both convinced it is safe, and in
>> off-list correspondence with Michael Cahill after he left Oracle,
>> he said that he dis
On Wed, Jun 01, 2011 at 06:16:21PM +0200, Florian Pflug wrote:
> On Jun1, 2011, at 03:17 , Florian Pflug wrote:
> > My nagging suspicion is that libxml reports errors like there via some
> > callback function, and only returns a non-zero result if there are
> > structural errors in the XML. But m
I wrote:
I think the most appropriate solution may be to disallow SELECT FOR
UPDATE/SHARE on sequences ... so if you have a good reason why we
shouldn't do so, please explain it.
Attached is a proposed patch to close off this hole. I found that
somebody had already inserted code to
On Sun, May 29, 2011 at 10:56:02AM -0400, Josh Kupershmidt wrote:
> On Sun, May 29, 2011 at 5:04 AM, Noah Misch wrote:
> > What risks arise from unconditionally allowing these calls for the same
> > user's
> > backends? ?`pg_cancel_backend' ought to be safe enough; the user always has
> > access
On Wed, Jun 01, 2011 at 04:58:36PM -0400, Robert Haas wrote:
> On Wed, Jun 1, 2011 at 4:47 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> I guess the real issue here is that m1.id < m2.id has to be evaluated
> >> as a filter condition rather than a join qual.
> >
> > Well, if you can invent an
On Wed, Jun 1, 2011 at 4:10 PM, Tom Lane wrote:
>
> I can't speak for Debian, but the above statement is 100% false for Red
> Hat. In any case, no RH system has ever expected users to issue pg_ctl
> start/stop directly, and I think the same is true for Debian, so the
> bizarre design wouldn't mat
Josh Berkus writes:
> pg_ctl -D means different things depending on whether you are calling
> "start" or "stop". For "start", pg_ctl wants the directory
> postgresql.conf is in, and for "stop" it wants the directory
> postmaster.pid is in. This means that if your .conf files are not in
> the sam
On Wed, Jun 1, 2011 at 4:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> I guess the real issue here is that m1.id < m2.id has to be evaluated
>> as a filter condition rather than a join qual.
>
> Well, if you can invent an optimized join technique that works for
> inequalities, go for it ... but
=?ISO-8859-1?Q?C=E9dric_Villemain?= writes:
> exact, thanks to your last email I read more the code and get the same
> conclusion and put it in a more appropriate place : before
> ExecScanHashBucket.
> I was about sending it, so it is attached.
Applied with cosmetic adjustments.
On 6/1/2011 11:43 AM, Pavel Golub wrote:
Hello.
I'm some kind of PQdeleteTuple function will be very usefull in libpq.
Because right now after deleting some record I need refetch result
set, or mark tuple as deleted and this is headache for me.
IMHO, this should be handled by the application.
Robert Haas writes:
> I guess the real issue here is that m1.id < m2.id has to be evaluated
> as a filter condition rather than a join qual.
Well, if you can invent an optimized join technique that works for
inequalities, go for it ... but I think you should get at least a
PhD thesis out of that.
On Wed, Jun 1, 2011 at 4:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 1, 2011 at 4:25 PM, Tom Lane wrote:
>>> Because of the way that a bitmap heap scan works, the rows are
>>> guaranteed to be loaded into the hash table in physical order, which
>>> means (in the fast case) that t
Robert Haas writes:
> On Wed, Jun 1, 2011 at 4:25 PM, Tom Lane wrote:
>> Because of the way that a bitmap heap scan works, the rows are
>> guaranteed to be loaded into the hash table in physical order, which
>> means (in the fast case) that the row with the largest "id" value gets
>> loaded last.
2011/6/1 Tom Lane :
> We do need to look into putting a CHECK_FOR_INTERRUPTS call in here
> somewhere, though. I'm inclined to think that right before the
> ExecScanHashBucket is the best place. The reason that nest and merge
> joins don't show a comparable non-responsiveness to cancels is that t
Florian Pflug writes:
> On Jun1, 2011, at 20:28 , Peter Eisentraut wrote:
>> Well, initdb still succeeds if you give it an invalid locale name. It
>> warns, but that can easily be missed if initdb is hidden behind a few
>> other layers. If you then run pg_upgrade, you get a hosed instance.
> Wh
On Wed, Jun 1, 2011 at 4:25 PM, Tom Lane wrote:
> Because of the way that a bitmap heap scan works, the rows are
> guaranteed to be loaded into the hash table in physical order, which
> means (in the fast case) that the row with the largest "id" value gets
> loaded last. And because ExecHashTable
Robert Haas writes:
> On Tue, May 31, 2011 at 11:47 PM, Tom Lane wrote:
>> I'd just write it off as being a particularly stupid way to find the
>> max(), except I'm not sure why deleting just a few thousand rows
>> improves things so much. It looks like it ought to be an O(N^2)
>> situation, so
Hello,
I partialy implemented following missing LOBs types. Requirement for this was
to give ability to create (B/C)LOB columns and add casting functionality e.g.
SET my_clob = 'My long text'.
Idea is as follow:
0. Blob is two state object: 1st in memory contains just bytea, serialized
contain
All,
pg_ctl -D means different things depending on whether you are calling
"start" or "stop". For "start", pg_ctl wants the directory
postgresql.conf is in, and for "stop" it wants the directory
postmaster.pid is in. This means that if your .conf files are not in
the same directory as data_direc
On Jun1, 2011, at 20:28 , Peter Eisentraut wrote:
> Well, initdb still succeeds if you give it an invalid locale name. It
> warns, but that can easily be missed if initdb is hidden behind a few
> other layers. If you then run pg_upgrade, you get a hosed instance.
Whats the rational behind that b
On ons, 2011-06-01 at 13:21 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> >>> I think you misread what I wrote, or I misexplained it, but never
> >>> mind. Matching locale names case-insensitively sounds reasonable to
> >>> me, unless someone has reason to believe it will blow up.
>
> > On
On 05/28/2011 02:58 PM, Peter Eisentraut wrote:
On fre, 2011-05-27 at 16:57 -0700, Steve Crawford wrote:
And the second case is already well handled. In fact calendaring is a
great example. I enter the time for the teleconference and PG nicely
uses my default timezone to store the point-in-time.
On Wed, Jun 1, 2011 at 8:58 AM, Jeff Janes wrote:
> In the latter case, wouldn't we just trigger the same inefficient
> scattered read of the data that normal database operation would
> trigger, taking about the same amount of time to reach cache-warmth?
If you have a system where you're bandwidt
Excerpts from Thom Brown's message of mar may 31 20:18:18 -0400 2011:
> test=# CREATE DOMAIN things AS INT CHECK (VALUE > 5);
> CREATE DOMAIN
> test=# CREATE TABLE abc (id SERIAL, stuff things);
> NOTICE: CREATE TABLE will create implicit sequence "abc_id_seq" for
> serial column "abc.id"
> CREAT
On 06/01/2011 12:55 PM, Robert Haas wrote:
On Wed, Jun 1, 2011 at 3:31 AM, Albe Laurenz wrote:
Peter Eisentrautwrote:
Excerpts from Brendan Jurd's message of mar may 31 02:17:22 -0400 2011:
openjade:information_schema.sgml:828:60:Q: length of name token must
not exceed NAMELEN (44)
But it
Peter Eisentraut writes:
>>> I think you misread what I wrote, or I misexplained it, but never
>>> mind. Matching locale names case-insensitively sounds reasonable to
>>> me, unless someone has reason to believe it will blow up.
> On FreeBSD, locale names appear to be case-sensitive:
> $ LC_ALL
On Wed, Jun 1, 2011 at 11:58 AM, Jeff Janes wrote:
> On Sun, May 15, 2011 at 11:19 AM, Robert Haas wrote:
>> I don't think there's any need for this to get data into
>> shared_buffers at all. Getting it into the OS cache oughta be plenty
>> sufficient, no?
>>
>> ISTM that a very simple approach
On Wed, Jun 1, 2011 at 3:31 AM, Albe Laurenz wrote:
> Peter Eisentrautwrote:
> Excerpts from Brendan Jurd's message of mar may 31 02:17:22 -0400 2011:
>> openjade:information_schema.sgml:828:60:Q: length of name token must
>> not exceed NAMELEN (44)
>>
>> But it seems like no one else
On Wed, Jun 1, 2011 at 1:30 AM, Tatsuo Ishii wrote:
>> Problem with the advisory lock is, it will not work if the target
>> table is empty.
>
> Oops. I was wrong. the key for advisory lock needs to be a unique
> value, but not necessarily a row value in a table. Seems this is the
> way I should go
2011/6/1 Pavel Golub :
> Hello.
>
> I'm some kind of PQdeleteTuple function will be very usefull in libpq.
> Because right now after deleting some record I need refetch result
> set, or mark tuple as deleted and this is headache for me.
>
> So I checked fe-exec.c sources and wrote this:
>
> int PQd
On Jun1, 2011, at 03:17 , Florian Pflug wrote:
> My nagging suspicion is that libxml reports errors like there via some
> callback function, and only returns a non-zero result if there are structural
> errors in the XML. But my experience with libxml is pretty limited, so maybe
> someone with mo
On Sun, May 15, 2011 at 11:19 AM, Robert Haas wrote:
> I don't think there's any need for this to get data into
> shared_buffers at all. Getting it into the OS cache oughta be plenty
> sufficient, no?
>
> ISTM that a very simple approach here would be to save the contents of
> each shared buffer
On tis, 2011-05-24 at 15:59 -0400, Bruce Momjian wrote:
> > I think you misread what I wrote, or I misexplained it, but never
> > mind. Matching locale names case-insensitively sounds reasonable to
> > me, unless someone has reason to believe it will blow up.
>
> OK, that's what I needed to hear.
Hello.
I'm some kind of PQdeleteTuple function will be very usefull in libpq.
Because right now after deleting some record I need refetch result
set, or mark tuple as deleted and this is headache for me.
So I checked fe-exec.c sources and wrote this:
int PQdeleteTuple(PGresult *src, int tup_num)
Fujii Masao writes:
> On Wed, Jun 1, 2011 at 12:30 PM, Tom Lane wrote:
>>> To address this corner
>>> case, we should check whether postmaster is really running by sending
>>> the signal 0 after we read postmater.pid file? Attached patch does that.
>> I find myself unimpressed by this approach,
On 11-06-01 09:30 AM, Christopher Browne wrote:
On Wed, Jun 1, 2011 at 8:29 AM, Dave Page wrote:
On Wed, Jun 1, 2011 at 12:27 PM, Andrew Dunstan wrote:
The whole point of the revamp was that pg_listener was a major performance
bottleneck and needed to go, and without it being gone we would no
On Wed, Jun 1, 2011 at 5:09 AM, Dave Page wrote:
> The pg_listener table was removed in 9.0 in the revamp of
> LISTEN/NOTIFY. In pgAdmin we used to perform a number of selects from
> the table to get information about Slony clusters - for example, the
> PID of the slon process or to check if a pro
On Wed, Jun 1, 2011 at 8:29 AM, Dave Page wrote:
> On Wed, Jun 1, 2011 at 12:27 PM, Andrew Dunstan wrote:
>>
>> The whole point of the revamp was that pg_listener was a major performance
>> bottleneck and needed to go, and without it being gone we would not have got
>> notification payloads.
>
>
On Wed, Jun 1, 2011 at 12:45 PM, Greg Sabino Mullane wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
>> The pg_listener table was removed in 9.0 in the revamp of
>> LISTEN/NOTIFY. In pgAdmin we used to perform a number of selects from
>> the table to get information about Slony
2011/6/1 Teodor Sigaev
>
> One of idea is add sorting of Datums to be splitted by cost of insertion.
> It's implemented in intarray/tsearch GiST indexes.
>
Yes, it's a good compromise between linear and quadratic entries
distribution algorithms. In quadratic algorithm each time entry with maximal
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> The pg_listener table was removed in 9.0 in the revamp of
> LISTEN/NOTIFY. In pgAdmin we used to perform a number of selects from
> the table to get information about Slony clusters - for example, the
> PID of the slon process or to check if a
Tom Lane-2 wrote:
>
> It looks like it ought to be an O(N^2)
> situation, so the improvement should be noticeable but not amazing.
>
Hm, the performance was reasonable again when doing a cluster...
So I believe this should be more a technical than an
algorithmical/complexity issue. Maybe it is
Ok, I can reproduce the issue with that. The index is only 4MB in size
when I populate it with random data (vs. 15 MB with your data). The
command I used is:
INSERT INTO cubtest SELECT cube(random(), random()) FROM
generate_series(1,2);
My guess is that the picksplit algorithm performs poorl
On Wed, Jun 1, 2011 at 12:27 PM, Andrew Dunstan wrote:
>
> The whole point of the revamp was that pg_listener was a major performance
> bottleneck and needed to go, and without it being gone we would not have got
> notification payloads.
Yeah, I know why it was replaced. That doesn't mean we cann
Hi!
I found problem while vacuuming with composite type (version 9.0.4). It's not so
easy to reproduce, but it's clear what happens.
CREATE TYPE mytype AS (p point, r float8);
CREATE TABLE mytable (mt mytype);
-- create opclass fir GiST
CREATE INDEX myidx ON mytable USING gist (mt);
And vacuu
On 06/01/2011 08:04 AM, Dave Page wrote:
On Wed, Jun 1, 2011 at 11:27 AM, Heikki Linnakangas
wrote:
On 01.06.2011 13:09, Dave Page wrote:
The pg_listener table was removed in 9.0 in the revamp of
LISTEN/NOTIFY. In pgAdmin we used to perform a number of selects from
the table to get informat
On Wed, Jun 1, 2011 at 3:37 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> My guess is that the picksplit algorithm performs poorly with that data.
> Unfortunately, I have no idea how to improve that.
Current cube picksplit function have no storage utilization guarantees,
On Wed, Jun 1, 2011 at 11:27 AM, Heikki Linnakangas
wrote:
> On 01.06.2011 13:09, Dave Page wrote:
>>
>> The pg_listener table was removed in 9.0 in the revamp of
>> LISTEN/NOTIFY. In pgAdmin we used to perform a number of selects from
>> the table to get information about Slony clusters - for exa
On Tue, May 31, 2011 at 11:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> With respect to the root of the issue (why does the anti-join take so
>> long?), my first thought was that perhaps the OP was very unlucky and
>> had a lot of values that hashed to the same bucket. But that doesn't
>> app
On 01.06.2011 10:48, Nick Raj wrote:
On Tue, May 31, 2011 at 12:46 PM, Heikki Linnakangas<
heikki.linnakan...@enterprisedb.com> wrote:
If not, please post a self-contained test case to create and populate the
table, so that others can easily try to reproduce it.
I have attached .sql file
On 01.06.2011 13:09, Dave Page wrote:
The pg_listener table was removed in 9.0 in the revamp of
LISTEN/NOTIFY. In pgAdmin we used to perform a number of selects from
the table to get information about Slony clusters - for example, the
PID of the slon process or to check if a process is listening
On 05/31/2011 05:41 PM, Alvaro Herrera wrote:
Excerpts from Josh Berkus's message of mar may 31 17:05:23 -0400 2011:
BTW, we talked to Debian about debbugs ages ago, and the Debian project
said that far too much of debbugs was not portable to other projects.
The good news is that the
The pg_listener table was removed in 9.0 in the revamp of
LISTEN/NOTIFY. In pgAdmin we used to perform a number of selects from
the table to get information about Slony clusters - for example, the
PID of the slon process or to check if a process is listening for a
specific notification. This allows
On 06/01/2011 03:03 AM, Tatsuo Ishii wrote:
Also I really want to see the performance comparison between these two
approaches in the real world database.
Well, tell me how big of a performance improvement you want PgFincore to
win by, and I'll construct a benchmark where it does that. If
2011/6/1 Tatsuo Ishii :
>> Yeah, I'm pretty well convinced this whole approach is a dead end.
>> Priming the OS buffer cache seems way more useful. I also think
>> saving the blocks to be read rather than the actual blocks makes a lot
>> more sense.
>
> Well, his proposal works on any platforms Po
On Wed, Jun 1, 2011 at 10:43, Dimitri Fontaine wrote:
> Alvaro Herrera writes:
>>> http://archives.beccati.org/
>>>
>>> It uses AOX (http://aox.org/) and as such is baked by a PostgreSQL
>>> database. The mails threading view is even a CTE.
>>
>> Yeah, it's great. Last time I heard, though, M
Alvaro Herrera writes:
>> http://archives.beccati.org/
>>
>> It uses AOX (http://aox.org/) and as such is baked by a PostgreSQL
>> database. The mails threading view is even a CTE.
>
> Yeah, it's great. Last time I heard, though, Mateo wasn't open to doing
> any more work on it (including fix
Peter Eisentrautwrote:
Excerpts from Brendan Jurd's message of mar may 31 02:17:22 -0400 2011:
> openjade:information_schema.sgml:828:60:Q: length of name token must
> not exceed NAMELEN (44)
>
> But it seems like no one else has seen this problem yet, so it's quite
> suspicious, since
On Wed, Jun 1, 2011 at 3:57 AM, Greg Stark wrote:
> I guess it was obvious but that was "expect the *penalty* function to
> obey the triangle inequality"
>
Actually, penalty function for boxes is even not commutative. Fox example:
A = ((0,0)-(1,1))
B = ((0,0)-(2,2))
penalty(A,B) = 3
penalty(B,A
> Yeah, I'm pretty well convinced this whole approach is a dead end.
> Priming the OS buffer cache seems way more useful. I also think
> saving the blocks to be read rather than the actual blocks makes a lot
> more sense.
Well, his proposal works on any platforms PostgreSQL supports. On the
other
87 matches
Mail list logo
