Tom Lane wrote:
Yeah, the main problem I have with TODO-on-a-wiki is the question of
quality control. I've been heard to complain that the TODO list
consists of everything Bruce thinks is a good idea, but for the most
part things don't get onto TODO without some rough consensus on the
mailing
Csaba Nagy wrote:
On Tue, 2006-08-08 at 12:36, Constantin Teodorescu wrote:
We have tried PGStatement#setPrepareThreshold with 1 as the threshold
but it's not a good solution.
Actually is worst. Considering that you have 5 different query plans,
you are selecting approx. random one of them,
Josh Berkus wrote:
Bruce,
OK, seems this should be a separate application, not done in the TODO
list, and I am not willing to take on that additional workload.
That's my feeling. But I think that we have enough people who are
interested to maintain it. If we don't, there was no point
Jim C. Nasby wrote:
Going one step further, if that item was in a system that allowed people
to get emails any time status changed then *everyone* who was interested
in that feature would immediately know that help was needed. I fail to
see how that's a bad thing.
Or maybe even more
Constantin Teodorescu wrote:
EXPLAIN VARIANTS SELECT .. (and so on) that will display the
different query plans analyzed by the planner and their estimated time
values , not just the best guess .
assuming that the EXPLAIN VARIANTS will show 3 or 4 different query
plans, the database
Josh Berkus wrote:
I doubt that any TODO system would have 100% participation, and I know that it
would depend on having some non-hacker volunteers updating the information on
behalf of developers who didn't want to use it. However, I think that
getting those volunteers is entirely possible
David Fetter wrote:
On Fri, Aug 04, 2006 at 02:37:56PM -0700, Neil Conway wrote:
On Fri, 2006-08-04 at 12:40 -0700, David Fetter wrote:
While I am not going to reopen the can of worms labeled 'bug
tracker', I think it would be good to have a little more formality
as far as claiming items
Josh Berkus wrote:
It's very nice to throw these things out there and put them on the TODO
list ... and if I had $100,000 in development money to throw at something, I
might spend it that way ... but to propose them as *immediate* solutions to
problems for 8.2 is fantasy.
Point taken.
Peter Eisentraut wrote:
Lukas Kahwe Smith wrote:
whereas PostgreSQL is continuously complaing that
MySQL is inferior yet way more popular. Maybe MySQL's popularity is not
even PostgreSQL's goal, but I am sure a bit more would be welcome.
Does MySQL have a monolithic distribution?
Well
Lukas Smith wrote:
Peter Eisentraut wrote:
Lukas Kahwe Smith wrote:
whereas PostgreSQL is continuously complaing that
MySQL is inferior yet way more popular. Maybe MySQL's popularity is not
even PostgreSQL's goal, but I am sure a bit more would be welcome.
Does MySQL have a monolithic
Lukas Smith wrote:
Lukas Smith wrote:
Peter Eisentraut wrote:
Lukas Kahwe Smith wrote:
whereas PostgreSQL is continuously complaing that
MySQL is inferior yet way more popular. Maybe MySQL's popularity is not
even PostgreSQL's goal, but I am sure a bit more would be welcome.
Does MySQL have
Joshua D. Drake wrote:
Aside from obviously the big issue of who maintains all the pgfoundry
stuff, I also think that the PostgreSQL family would benefit from a
distribution that is more and the kitchen sink style. I do not know
exactly if Bizgres could be considered just that? Or maybe it
Tom Lane wrote:
Basically there's no free lunch: if you want the benefits of MVCC it's
going to cost you somewhere. In the Postgres design you pay by having
to do VACUUM pretty often for heavily-updated tables. I don't think
that decision is fundamentally wrong --- the attractive thing about
Jochem van Dieten wrote:
make the session handler smarter? And if you can't do that, put some
logic in the session table that turns an update without changes into a
no-op?
err isnt that one the job of the database?
regards,
Lukas
---(end of
Greg Stark wrote:
There are other solutions too. I never used DB2 but I was led to believe they
used their transaction log to retrieve old versions of the records. Someone
else here claimed DB2 didn't implement MVCC at all so perhaps that's wrong
though.
I would be suprised giving this paper:
Hi,
I was just talking to Derick the author of DBGp and I realized this
might be a topic for a joint effort among all open source RDBMS. I think
it would be awesome if we could get a common protocol setup for stored
procedure debugging.
regards,
Lukas
---(end of
Thomas Hallgren wrote:
I'd use the Komodo IDE and implement the ability to start the PL using a
GUC setting per my original suggestion (with super-user requirement).
Trivial solution, minimum effort, and very useful. KISS principle.
The DBGp protocol [1] I mentioned earlier is used by Komodo
Thomas Hallgren wrote:
Ideally, all pl's should use the same protocol. It should be language
agnostic and allow different regions of the code to origin from
different languages. That way, it would be possible to single step a
plpgsql function that in turn calls a function in pljava.
Hi,
I really think that PostgreSQL could benefit from a packaged solution
that incorporates a lot of the contrib stuff (tsearch2, maybe even some
replication setups ..). I really like the approach that PostgreSQL is a
clean yet highly extensible base from which other people can build their
Joshua D. Drake wrote:
Thomas Hallgren wrote:
John DeSoi wrote:
Right, you'll definitely need to hack the C source code to force
PostgreSQL to accept invalid dates ;)
http://sql-info.de/mysql/gotchas.html#1_14
Couldn't we just install something that replaced invalid dates with a
randomly
Tom Lane wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
Yesterday I helped a guy on irc with a locking problem, he thought
that locking in postgresql was broken. It turned out that he had a PHP
function that he called inside his transaction and the function did BEGIN
and COMMIT. Since BEGIN
hubert depesz lubaczewski wrote:
i have number of projects coming to my mind which could take advantage
of something like this. the simplest thing is e-commerce site, where all
custom fields (fields dependand on product type) can be stored in one,
easily retrievable, field - thus reducing
Jim C. Nasby wrote:
On Mon, May 01, 2006 at 11:25:33AM -0400, Tom Lane wrote:
[EMAIL PROTECTED] writes:
Ah. I was wondering about that. When I saw the first poster tag
'SECURITY DEFINER' on the end of the expression I assumed it was
something that I didn't know you could do... :-)
No, he was
Jonah H. Harris wrote:
Again, I haven't really used it, but have read over the docs briefly.
I'm just wondering if anyone has used it and likes/dislikes it.
I guess you could get the same effect from a transaction. If there is
much network overhead you could also write a stored procedure.
Jonah H. Harris wrote:
In the end, how is this more efficient or easy than:
INSERT INTO test_tbl VALUES (nextval('test_id_seq'), 'John Doe')
RETURNING test_id;
OR
SELECT test_id FROM NEW TABLE INSERT INTO test_tbl VALUES
(nextval('test_id_seq'), 'John Doe');
Based on your statement, this
Alvaro Herrera wrote:
AFAIR they got a private scan done and they fixed the reported defects.
After that they issued a press release telling how little defects they
got, or something ...
OTOH neither JBoss, BerkeleyDB, Qt are listed. Is there a pattern here?
I guess the pattern is obvious
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
A simple hack might help with a subset of this problem, though. For
queries with both ORDER BY and GROUP BY clauses, we can sort the
grouping columns according to their position in the ORDER BY list. So,
given a query like:
SELECT a, b,
Kevin Grittner wrote:
I rewrote the query to use IN predicates rather than EXISTS predicates,
and the cost estimates look like this:
EXISTS, no index: 1.6 billion
EXISTS, with index: 0.023 billion
IN, no index: 13.7 billion
IN, with index: 10.6 billion
At least for the two EXISTS cases,
Tom Lane wrote:
worse --- in the first place there are severe performance issues
associated with unindexed foreign-key checks, and in the second place
there is the foot-gun problem that you might forget to re-add the
indexes at all.
MySQL has a syntax in ALTER TABLE similar to PGSQL's
Michael Glaesemann wrote:
During Josh Berkus' presentation at the JPUG PostgreSQL Conference, I
was particularly struck by the fact that 8.1 had a shorter beta period
than previous releases, rolled out on time, and enjoyed a longer period
before the first post-release bug was reported. The
Christopher Kings-Lynne wrote:
http://www.flamingspork.com/blog/2006/02/16/enterprisedb-where-is-the-source/
Any comments on this? Is he referring to EnterpriseDB extensions that
they don't make public?
I think so. Trying to battle the perception that EnterpriseDB is an
open source
Michael Glaesemann wrote:
On Jan 13, 2006, at 21:42 , Leandro Guimarães Faria Corcete DUTRA wrote:
If you still declare the natural key(s) as UNIQUEs, you have just made
performance worse. Now there are two keys to be checked on UPDATEs and
INSERTs, two indexes to be updated, and probably a
Rod Taylor wrote:
If you still declare the natural key(s) as UNIQUEs, you have just made
performance worse. Now there are two keys to be checked on UPDATEs and
INSERTs, two indexes to be updated, and probably a SEQUENCE too.
Indeed. Using a surrogate key is not free and that is why it would
Simon Riggs wrote:
- yes, the random sampling is random - please read the code and comments
- yes, I would expect the results you get. If you sample 5% of rows and
each block has on average at least 20 rows, then we should expect the
majority of blocks to be hit.
and it seems from the
this feedback loop can be even directly used
by the server itself.
regards,
Lukas Smith
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Jim C. Nasby wrote:
Now, if both of these are done using a prepared statement, it's going to
look like:
SELECT * FROM queue WHERE status='?';
If the first one to run is the queue processing one, the planner will
probably choose the index. This means that when we're searching on 'N',
there
Bruce Momjian wrote:
Maybe I am mixing up separate concepts (are bound variables and prepared
statements different concepts?) here. I also do not really understand if
that means that oracle does not store a query plan for a prepared query
or if it just does some special handling in case it
Bruce Momjian wrote:
It is an issue for all databases. We gave a TODO about it:
* Flush cached query plans when the dependent objects change,
when the cardinality of parameters changes dramatically, or
when new ANALYZE statistics are available
Ok, just so I
Bruce Momjian wrote:
* Flush cached query plans when the dependent objects change,
when the cardinality of parameters changes dramatically, or
when new ANALYZE statistics are available
Wouldn't it also make sense to flush a cached query plan when after
execution
39 matches
Mail list logo
