Sorry, I'm not real familiar with pgpool, but have you thought about
using an advisory lock on the target table, instead of a real lock
(SELECT ... FOR UPDATE / LOCK table)? An advisory lock should not
interfere with autovacuum. Obviously, this would only work if all the
INSERTs in your
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
On Wed, Jun 1, 2011 at 3:57 AM, Greg Stark gsst...@mit.edu 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
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 surely people
Alvaro Herrera alvhe...@commandprompt.com 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
On Wed, Jun 1, 2011 at 10:43, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
2011/6/1 Tatsuo Ishii is...@postgresql.org:
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
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
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
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
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 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 Tue, May 31, 2011 at 11:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Wed, Jun 1, 2011 at 11:27 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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 06/01/2011 08:04 AM, Dave Page wrote:
On Wed, Jun 1, 2011 at 11:27 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
On Wed, Jun 1, 2011 at 12:27 PM, Andrew Dunstan and...@dunslane.net 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
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
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 the
-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
2011/6/1 Teodor Sigaev teo...@sigaev.ru
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
On Wed, Jun 1, 2011 at 12:45 PM, Greg Sabino Mullane g...@turnstep.com 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
On Wed, Jun 1, 2011 at 8:29 AM, Dave Page dp...@pgadmin.org wrote:
On Wed, Jun 1, 2011 at 12:27 PM, Andrew Dunstan and...@dunslane.net 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
On Wed, Jun 1, 2011 at 5:09 AM, Dave Page dp...@pgadmin.org 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
On 11-06-01 09:30 AM, Christopher Browne wrote:
On Wed, Jun 1, 2011 at 8:29 AM, Dave Pagedp...@pgadmin.org wrote:
On Wed, Jun 1, 2011 at 12:27 PM, Andrew Dunstanand...@dunslane.net wrote:
The whole point of the revamp was that pg_listener was a major performance
bottleneck and needed to go,
Fujii Masao masao.fu...@gmail.com writes:
On Wed, Jun 1, 2011 at 12:30 PM, Tom Lane t...@sss.pgh.pa.us 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
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
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. I
On Sun, May 15, 2011 at 11:19 AM, Robert Haas robertmh...@gmail.com 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
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 more
2011/6/1 Pavel Golub pa...@microolap.com:
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
On Wed, Jun 1, 2011 at 1:30 AM, Tatsuo Ishii is...@postgresql.org 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
On Wed, Jun 1, 2011 at 3:31 AM, Albe Laurenz laurenz.a...@wien.gv.at 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
On Wed, Jun 1, 2011 at 11:58 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Sun, May 15, 2011 at 11:19 AM, Robert Haas robertmh...@gmail.com 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?
Peter Eisentraut pete...@gmx.net 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:
$
On 06/01/2011 12:55 PM, Robert Haas wrote:
On Wed, Jun 1, 2011 at 3:31 AM, Albe Laurenzlaurenz.a...@wien.gv.at 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
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
CREATE TABLE
On Wed, Jun 1, 2011 at 8:58 AM, Jeff Janes jeff.ja...@gmail.com 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
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
On ons, 2011-06-01 at 13:21 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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 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
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_directory,
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
Robert Haas robertmh...@gmail.com writes:
On Tue, May 31, 2011 at 11:47 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jun 1, 2011 at 4:25 PM, Tom Lane t...@sss.pgh.pa.us 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
Florian Pflug f...@phlo.org 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
2011/6/1 Tom Lane t...@sss.pgh.pa.us:
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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 1, 2011 at 4:25 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jun 1, 2011 at 4:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 1, 2011 at 4:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Because of the way that a bitmap heap scan works, the rows are
guaranteed to be loaded into the hash table in physical
Robert Haas robertmh...@gmail.com 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
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
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com 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
On Wed, Jun 1, 2011 at 4:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Josh Berkus j...@agliodbs.com 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
On Wed, Jun 1, 2011 at 4:10 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jun 01, 2011 at 04:58:36PM -0400, Robert Haas wrote:
On Wed, Jun 1, 2011 at 4:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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.
On Sun, May 29, 2011 at 10:56:02AM -0400, Josh Kupershmidt wrote:
On Sun, May 29, 2011 at 5:04 AM, Noah Misch n...@leadboat.com 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
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 forbid the
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 my
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On Wed, Jun 1, 2011 at 5:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com 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
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
PostgreSQL
On Wed, Jun 1, 2011 at 6:04 PM, Tom Lane t...@sss.pgh.pa.us 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
Teodor Sigaev teo...@sigaev.ru 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
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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 1, 2011 at 6:04 PM, Tom Lane t...@sss.pgh.pa.us 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
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. In
Alvaro Herrera alvhe...@commandprompt.com 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
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 to
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
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 dependency?
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
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.
--
On 1 June 2011 23:47, Alvaro Herrera alvhe...@commandprompt.com 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
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 provide
Alvaro Herrera alvhe...@commandprompt.com 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
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
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 new data
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 Davis
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
On Wed, Jun 1, 2011 at 8:18 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Wed, Jun 1, 2011 at 5:55 PM, Noah Misch n...@leadboat.com 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
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 01, 2011 at 10:26:34PM -0400, Josh Kupershmidt wrote:
On Wed, Jun 1, 2011 at 5:55 PM, Noah Misch n...@leadboat.com 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
2011/6/1 Alexander Korotkov aekorot...@gmail.com
2011/6/1 Teodor Sigaev teo...@sigaev.ru
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
86 matches
Mail list logo
