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 pa
2009/8/21 Jeff Davis :
> 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), if a user
> 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 assig
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.indisuniq
On Fri, Aug 21, 2009 at 3:23 AM, Brendan Jurd 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?
There are no i
2009/8/21 Jeff Davis :
> 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 may be an opp
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 co
2009/8/21 Heikki Linnakangas :
> 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 permissions, create
triggers, cha
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
> 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:
ht
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
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 as a production for the expression
at the right of th
> 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
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 accept
Tom Lane napsal(a):
Peter Eisentraut 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 tell the fu
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
Greg Stark 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 behavior. Specific
On Thu, Aug 20, 2009 at 6:28 PM, Greg Stark 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 this topic comes
On Thu, Aug 20, 2009 at 6:10 PM, Robert Haas 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. Also, it doesn't te
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 speci
On Thu, Aug 20, 2009 at 12:55 PM, Kevin
Grittner wrote:
> Robert Haas 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
Robert Haas 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 cost much and
>
On Thu, Aug 20, 2009 at 12:40 PM, Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>>
>> Andrew Dunstan 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
>
Andrew Dunstan 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 and
>> as alternatives to just below .
> What causes those to happen?
You can get a via explaining a command that's been
Tom Lane wrote:
Andrew Dunstan 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 and
as alternatives to ju
On Thu, Aug 20, 2009 at 11:15 AM, decibel 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 to have dealt wi
On Thu, Aug 20, 2009 at 4:13 PM, Ygor Degani 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. Do you have more
Andrew Dunstan 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 and
as alternatives to just below .
Also, it look
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 autocreated
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, non-contro
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 me
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
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 w
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
Andrew Dunstan 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 thing? And in a
On Thu, Aug 20, 2009 at 9:30 AM, Andrew Dunstan 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 w
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 littl
On Thu, Aug 20, 2009 at 1:55 AM, Heikki
Linnakangas 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 little more. I'm wonder
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:
>
> CREAT
39 matches
Mail list logo
