Itagaki Takahiro wrote:
However, automatic transaction management needs help by core. Is it
acceptable to have two-phase callbacks?
Probably, but it's far too early to decide what the interface should
look like.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent
Jeff Davis wrote:
I'm going to try to get this patch ready for the 9-15 commitfest. Here
are a few design updates:
(1) Language:
I think that the new language should be a table constraint, and I think
there's a consensus on that. The specific language I have in mind is:
CREATE TABLE
On Thu, Aug 20, 2009 at 1:55 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
When that is replayed, ProcArrayUpdateTransactions() will zap the
unobserved xids array with the list that includes XID 123, even though
we already saw a commit record for it.
I looked at this a
Andrew Dunstan wrote:
Bruce Momjian wrote:
Are we going to publish an XML DTD for EXPLAIN, or have we already?
Not a DTD, but I am working on an XML Schema (DTDs are a bit yesterday).
Here is a RelaxNG spec which people might find a bit easier to read. It
has been autocreated by a
On Thu, Aug 20, 2009 at 9:30 AM, Andrew Dunstanand...@dunslane.net wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Are we going to publish an XML DTD for EXPLAIN, or have we already?
Not a DTD, but I am working on an XML Schema (DTDs are a bit yesterday).
Here is a RelaxNG spec
Andrew Dunstan and...@dunslane.net writes:
I have a couple of questions, however. First, in that long list of
alternatives for a Plan node, can any of them occur more than once?
No.
Second, we are using Item as a child of both Output and Sort-Key nodes.
Are they really describing the same
When recover a database using a continuous archive backup, i detected some
duplicated keys. This there isn't in the production database.
I use postgres-8.3.5.
anyone know why this happens?
Regards,
--
Ygor Degani
On Thu, 2009-08-20 at 11:47 +0300, Heikki Linnakangas wrote:
That sounds like the constraint is based on an existing index, but there
can't be any existing indexes on a table that hasn't been created yet.
If this creates the index, then the syntax needs to support specifying
index access
Due to a thread about the neglect of the sample start scripts I took a
look at the current Linux file. There's certainly room for several
improvements, but some of them might require discussion. Attached are
a couple small changes which seem to me to be pretty tame. Hopefully
a small,
There have been a number of planner improvement ideas that have been
thrown out because of the overhead they would add to the planning
process, specifically for queries that would otherwise be quiet fast.
Other databases seem to have dealt with this by creating plan caches
(which might be
When recover a database using a continuous archive backup, i detected some
duplicated keys. This there isn't in the production database.
I use postgres-8.3.5.
anyone know why this happens?
Regards,
--
Ygor Degani
I wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Are we going to publish an XML DTD for EXPLAIN, or have we already?
Not a DTD, but I am working on an XML Schema (DTDs are a bit yesterday).
Here is a RelaxNG spec which people might find a bit easier to read.
It has been
Andrew Dunstan and...@dunslane.net writes:
Updated version with more complete information (regression crash was due
to my bad script).
I took a look through the source code to match it against this. I found
that you missed a couple of possibilities: we have Notify / and
Utility-Statement / as
On Thu, Aug 20, 2009 at 4:13 PM, Ygor Deganiygordeg...@gmail.com wrote:
When recover a database using a continuous archive backup, i detected some
duplicated keys. This there isn't in the production database.
I use postgres-8.3.5.
anyone know why this happens?
Uhm, well it's not supposed to.
On Thu, Aug 20, 2009 at 11:15 AM, decibeldeci...@decibel.org wrote:
There have been a number of planner improvement ideas that have been thrown
out because of the overhead they would add to the planning process,
specifically for queries that would otherwise be quiet fast. Other databases
seem
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Updated version with more complete information (regression crash was due
to my bad script).
I took a look through the source code to match it against this. I found
that you missed a couple of possibilities: we have Notify /
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
I took a look through the source code to match it against this. I found
that you missed a couple of possibilities: we have Notify / and
Utility-Statement / as alternatives to Query just below explain.
What causes those to happen?
On Thu, Aug 20, 2009 at 12:40 PM, Andrew Dunstanand...@dunslane.net wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Updated version with more complete information (regression crash was due
to my bad script).
I took a look through the source code to match it against
Robert Haas robertmh...@gmail.com wrote:
I think one of the problems with the planner is that all decisions
are made on the basis of cost. Honestly, it works amazingly well in
a wide variety of situations, but it can't handle things like we
might as well materialize here, because it doesn't
On Thu, Aug 20, 2009 at 12:55 PM, Kevin
Grittnerkevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
I think one of the problems with the planner is that all decisions
are made on the basis of cost. Honestly, it works amazingly well in
a wide variety of situations, but
Jeff Davis wrote:
On Thu, 2009-08-20 at 11:47 +0300, Heikki Linnakangas wrote:
That sounds like the constraint is based on an existing index, but there
can't be any existing indexes on a table that hasn't been created yet.
If this creates the index, then the syntax needs to support specifying
On Thu, Aug 20, 2009 at 6:10 PM, Robert Haasrobertmh...@gmail.com wrote:
Maybe. The problem is that we have mostly two cases: an estimate that
we think is pretty good based on reasonable statistics (but may be way
off if there are hidden correlations we don't know about), and a wild
guess.
On Thu, Aug 20, 2009 at 6:28 PM, Greg Starkgsst...@mit.edu wrote:
I don't think it's a bad idea, I just think you have to set your
expectations pretty low. If the estimates are bad there isn't really
any plan that will be guaranteed to run quickly.
Actually this is usually Tom's point when
Greg Stark gsst...@mit.edu wrote:
Say you're deciding between an index scan and a sequential scan. The
sequential scan has a total cost of 1000..1000 but the index scan
has an estimated total cost of 1..1.
My proposal was to use RMS, which would effectively favor lower worst
case
I'm writing some code now that uses the inet and cidr types and I find
myself wanting a function that takes an argument of type inet and
returns an integer, where:
255.255.255.255 = 32
255.255.255.254 = 31
255.255.255.252 = 30
255.255.255.248 = 29
255.255.255.240 = 28
...
128.0.0.0 = 1
0.0.0.0 =
Tom Lane napsal(a):
Peter Eisentraut pete...@gmx.net writes:
Well, I don't know if we really need to call it lambda, but I fully
expect to be able to use these ad hoc functions as part of other
expressions.
Why would you expect that? To be used in an expression, you'd also need
decoration to
Petr Jelinek wrote:
The implementation as I see it would create function in pg_temp
namespace, call it and then drop it. Any other implementation would
imho mean rewriting procedure language api.
That's really ugly. It'll cause catalog bloat with every execution.
I think it would be
How are your duplicate keys being generated? Is there a unique index on
them?
They are generated during recover. Yes, there is a unique index.
Are the keys there if you use a sequential scan or only if you use an
index to look them up?
I used a sequential scan.
Have you been running 8.3.5 the
Hi,
I've been having a look around to see what would it take to implement
the syntax in the subject, completing a patch posted by Sussane Ebrecht
two years ago.
As far as I can tell, the first problem is in the grammar. The SQL spec
mandates multiple value expression as a production for the
Alvaro Herrera wrote:
But then there's the matter of how to represent it from the grammar
inwards. At first I thought of creating a new parse node type, say
MultiResTarget that would replace ResTarget in UpdateStmt, and get it
from there into the optimizer and executor.
Hmm, I should be
Anyone else think this would be a useful addition? Anyone have a good
idea for a name? parse_netmask()?
netmask_bits()
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
In a federated database engine I built in the mid-90's,
it more or less ran both plans in parallel, to implement fast-first and
min-total cost.
The index query in general started returning rows whose oids went into a filter
that discarded them from the serial query once it started to crank things
2009/8/21 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Jeff Davis wrote:
I'm leaning toward not allowing it at CREATE TABLE time.
Seems reasonable to me too.
+1
There are plenty of other things to do with tables that you can't mix
directly into a CREATE TABLE statement (grant
On Fri, 2009-08-21 at 11:14 +1000, Brendan Jurd wrote:
As an aside, Jeff, have you considered how this feature would interact
with CREATE TABLE ... LIKE parent_table [ { INCLUDING | EXCLUDING } {
DEFAULTS | CONSTRAINTS | INDEXES } ] ... }? What if someone asks to
include indexes but not
2009/8/21 Jeff Davis pg...@j-davis.com:
If they include indexes and not constraints, I think we should follow
the same policy as unique constraints, and create the index and the
constraint.
The behavior seems a little strange to me, but that's the current
behavior for unique indexes.
This
On Fri, Aug 21, 2009 at 3:23 AM, Brendan Jurddire...@gmail.com wrote:
They'd expect it to create an index sans the unique
constraint. Ignoring the user's intention and copying the index as-is
(including the unique constraint) would be unfriendly.
Unless the SQL spec demands that we do so?
On Fri, 2009-08-21 at 12:23 +1000, Brendan Jurd wrote:
This may be an opportunity to fix it.
The current behaviour seems to be predicated on the unique constraint
being an integral part of the index itself. While this might be true
from a system catalog point of view (pg_index.indisunique),
I don't think it's a bad idea, I just think you have to set your
expectations pretty low. If the estimates are bad there isn't really
any plan that will be guaranteed to run quickly.
Well, the way to do this is via a risk-confidence system. That is, each
operation has a level of risk
2009/8/21 Jeff Davis pg...@j-davis.com:
On Fri, 2009-08-21 at 12:23 +1000, Brendan Jurd wrote:
The current behaviour seems to be predicated on the unique constraint
being an integral part of the index itself. While this might be true
from a system catalog point of view (pg_index.indisunique),
Hi Alvaro,
But then there's the matter of how to represent it from the grammar
inwards. At first I thought of creating a new parse node type, say
MultiResTarget that would replace ResTarget in UpdateStmt, and get it
from there into the optimizer and executor.
Hmm, I should be passing it
40 matches
Mail list logo
