Tom Lane wrote:
> KaiGai Kohei <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> * It does not come close to passing the regression tests. I saw a lot of
>>> ! ERROR: unrecognized node type: 903
>>> which suggests that something's been screwed up about parse analysis
>>> (903 = T_A_Const, which
Hi guys, I am new to postgres hacking, and I have the following question.
Say that someone executes a query:
SELECT * FROM user u, logins l WHERE u.id = l.id
(assume I have tables user, and logins, with id fields).
After this query has been parsed and created into a plan tree, how can I
get the c
On Thu, 2008-05-08 at 00:41 -0400, Tom Lane wrote:
> Tino Wildenhain <[EMAIL PROTECTED]> writes:
> > I may be wrong but my feeling is, not to much weirdness in the core
> > please :)
>
> +1 ... we have wasted more than enough man-hours trying to get the magic
> "serial" type to play nicely. If I
Yesterday a client and I were sad to discover that the overhead of
constraint exclusion is apparently O(n) in the number of partitions, and
that where we had ~180 partitions each with a simple constraint (check
(field = nnn)) the overhead appeared to amount to about 0.25s on some
quite perfor
On Fri, 2008-05-09 at 08:47 -0400, Andrew Dunstan wrote:
> However, I wondered if we couldn't mitigate this by caching the results
> of constraint exclusion analysis for a particular table + condition. I
> have no idea how hard this would be, but in principle it seems silly to
> keep paying the
On Thu, May 08, 2008 at 08:44:46AM +0200, Martijn van Oosterhout wrote:
> On Wed, May 07, 2008 at 03:04:49PM -0700, David Fetter wrote:
> > 1. Create a generic (possibly overloaded) trigger function,
> > bundled with PostgreSQL, which sets a field to some value. For
> > example, a timestamptz ver
On May 7, 2008, at 4:52 PM, David Fetter wrote:
When I do CREATE TABLE foo(LIKE bar INCLUDING CONSTRAINTS), it doesn't
include foreign key constraints (8.3.1). I believe this is surprising
behavior, but maybe not a bug, so I'd like to propose another bit of
syntactic sugar, namely
LIKE [INC
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Yesterday a client and I were sad to discover that the overhead of
> constraint exclusion is apparently O(n) in the number of partitions, and
> that where we had ~180 partitions each with a simple constraint (check
> (field = nnn)) the overhead appear
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Actual execution of the query in question was talking one tenth of that
> time.
>...
> but in principle it seems silly to keep paying the same penalty over and
> over again.
I would think constraint_exclusion only really makes sense if you're spendin
KaiGai Kohei <[EMAIL PROTECTED]> writes:
> Some of the test fails contains minor differences from expected results, like:
> | SELECT '' AS "xxx", *
> | FROM J1_TBL t1 (a, b, c) NATURAL JOIN J2_TBL t2 (d, a);
> |xxx | a | b | c | d
> | -+---+---+--+---
> | - | 0 | | ze
On Fri, 2008-05-09 at 08:47 -0400, Andrew Dunstan wrote:
> Yesterday a client and I were sad to discover that the overhead of
> constraint exclusion is apparently O(n) in the number of partitions, and
> that where we had ~180 partitions each with a simple constraint (check
> (field = nnn)) the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Guillaume Smet wrote:
>> I understand your point of view but I really think it's more a
>> regression fix than a behavior change.
> If I can get other hackers to say we should backpatch we can consider
> it.
Well, 8.3 is already different from 8.2, and
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Guillaume Smet wrote:
> >> I understand your point of view but I really think it's more a
> >> regression fix than a behavior change.
>
> > If I can get other hackers to say we should backpatch we can consider
> > it.
>
> Well, 8.3 i
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Well, 8.3 is already different from 8.2, and a lot of people will see
>> this particular aspect of it as a regression. I'm okay with
>> backpatching to 8.3 ... though the patch needed rather more testing
>> than you gave it.
> OK, so
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> Log Message:
>> ---
>> Improve logic for finding object files on OBJS lines in contrib Makefiles.
>> If this unbreaks buildfarm mastodon, apply everywhere.
> I start to wonder why don't we just implement our own make in
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
Log Message:
---
Improve logic for finding object files on OBJS lines in contrib Makefiles. If
this unbreaks buildfarm mastodon, apply everywhere.
I start to wonder why don't we just
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >
> >> Andrew Dunstan wrote:
> >>
> >>> Log Message:
> >>> ---
> >>> Improve logic for finding object files on OBJS lines in contrib
> >>> Makefiles. If this unbreaks buildfarm mastodon, a
The "TRUNCATE table while we're holding references to it" bug (3883), is
causing an assertion failure on 8.2, when the TRUNCATE is called in a
trigger:
Script:
CREATE TABLE proc(n int);
INSERT INTO proc VALUES (9);
CREATE OR REPLACE FUNCTION deltrig() RETURNS trigger LANGUAGE plpgsql AS $$
BE
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>>
>>> Andrew Dunstan wrote:
>>>
Log Message:
---
Improve logic for finding object files on OBJS lines in contrib Makefiles.
If this unbreaks buildfarm mastodon, apply ever
Now that psql '\pset format wrapped' is in CVS, we should consider when
we want to use 'wrapped' format by default. I think psql \df and \dT
certainly can benefit from wrapped mode. \df+ even displays, though
there is quite a bit of wrapping.
The attached patch uses wrapped format for \d* output
Hi, hackers.
I've been fooling around my GSoC project, and here's the first version
I'm not actually ashamed of showing.
There's one fundamental problem I came across while writing a typanalyze
function for tsvectors.
update_attstats() constructs an array that's later inserted into the
appro
On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Now that psql '\pset format wrapped' is in CVS, we should consider when
> we want to use 'wrapped' format by default. I think psql \df and \dT
> certainly can benefit from wrapped mode. \df+ even displays, though
> there
Brendan Jurd escribió:
> On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Now that psql '\pset format wrapped' is in CVS, we should consider when
> > we want to use 'wrapped' format by default. I think psql \df and \dT
> > certainly can benefit from wrapped mode. \df+
On Sat, May 10, 2008 at 4:37 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Brendan Jurd escribió:
>> I for one would definitely like backslash commands with very wide
>> output to be wrapped by default.
>
> (At least) one place where I would not like it is in \df+, because
> wrapped function outp
* Brendan Jurd <[EMAIL PROTECTED]> [080509 14:43]:
> On Sat, May 10, 2008 at 4:37 AM, Alvaro Herrera
> <[EMAIL PROTECTED]> wrote:
> > Brendan Jurd escribió:
> >> I for one would definitely like backslash commands with very wide
> >> output to be wrapped by default.
> >
> > (At least) one place wher
Hi,
I noticed heapam.h is included in way too many places. This is bad IMHO
because heapam.h itself includes a lot of other headers.
A lot of these are easy to fix; the source files just need to include
some other headers. Standard cleanup, I don't think anybody would
object to that. For examp
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>
> > Actual execution of the query in question was talking one tenth of that
> > time.
> >...
> > but in principle it seems silly to keep paying the same penalty over and
> > over again.
>
> I would think c
Brendan Jurd wrote:
[ email paragraphs reordered.]
> I seem to recall there was some discussion of an "auto" mode in the
> original wrapping thread, but if there was any meaningful conclusion I
> lost it in amongst the width detection flame war.
I wasn't going to bring up the 'auto' idea yet bec
Jan Urbański wrote:
I've been fooling around my GSoC project, and here's the first version
I'm not actually ashamed of showing.
Oh, wow, at this speed you'll be done before the summer even starts ;-)
There's one fundamental problem I came across while writing a typanalyze
function for tsvecto
Stephen Frost wrote:
* Gregory Stark ([EMAIL PROTECTED]) wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
Actual execution of the query in question was talking one tenth of that
time.
...
but in principle it seems silly to keep paying the same penalty over and
over again.
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
>> Seems like that'd make more sense the changing it to use the child
>> tables directly.. Just my 2c.
>
> This is actually a technique already used elsewhere in the app, so it
> will fit quite well. Thanks for the suggestion, though.
Sure.
> (BTW, w
>>> "Brendan Jurd" <[EMAIL PROTECTED]> wrote:
> On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian <[EMAIL PROTECTED]>
wrote:
>> Now that psql '\pset format wrapped' is in CVS, we should consider
when
>> we want to use 'wrapped' format by default. I think psql \df and
\dT
>> certainly can benefit fro
Brendan Jurd wrote:
> On Sat, May 10, 2008 at 4:37 AM, Alvaro Herrera
> <[EMAIL PROTECTED]> wrote:
> > Brendan Jurd escribi?:
> >> I for one would definitely like backslash commands with very wide
> >> output to be wrapped by default.
> >
> > (At least) one place where I would not like it is in \df
Aidan Van Dyk wrote:
-- Start of PGP signed section.
> * Brendan Jurd <[EMAIL PROTECTED]> [080509 14:43]:
> > On Sat, May 10, 2008 at 4:37 AM, Alvaro Herrera
> > <[EMAIL PROTECTED]> wrote:
> > > Brendan Jurd escribi?:
> > >> I for one would definitely like backslash commands with very wide
> > >> o
Kevin Grittner wrote:
> >>> "Brendan Jurd" <[EMAIL PROTECTED]> wrote:
> > On Sat, May 10, 2008 at 3:52 AM, Bruce Momjian <[EMAIL PROTECTED]>
> wrote:
> >> Now that psql '\pset format wrapped' is in CVS, we should consider
> when
> >> we want to use 'wrapped' format by default. I think psql \df an
>>> On Fri, May 9, 2008 at 3:53 PM, in message
<[EMAIL PROTECTED]>, Bruce Momjian
<[EMAIL PROTECTED]> wrote:
> test=> \pset format wrapped
> Output format is wrapped.
> test=> \pset columns 50
> Target width for "wrapped" format is 50.
> test=> explain analyze select
Kevin Grittner wrote:
> >>> On Fri, May 9, 2008 at 3:53 PM, in message
> <[EMAIL PROTECTED]>, Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> > test=> \pset format wrapped
> > Output format is wrapped.
> > test=> \pset columns 50
> > Target width for "wrapped" format is 50.
> >
Bruce Momjian escribió:
> Of course, running it on a 50-column display in 'aligned' mode isn't
> going to look good either.
This is what I get by pasting from a 50-column aligned psql (8.3):
QUERY PLAN
>>> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Bruce Momjian escribió:
> My conclusion is that we have to make very sure that "wrapped" is
not
> the default for explain.
This will cause me similar pain in other areas.
I'm glad I thought of an example with which others could easily
identify.
Hi everyone,
This question may have an obvious answer I have somehow missed, but to what
extent is locking order deterministic in PostgreSQL? For example, if
requests from multiple transactions arrive in some deterministic order and
acquire locks, can one assume that locks will be granted in the
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> [ patch to change inherited-check-constraint behavior ]
Applied after rather heavy editorializations. You didn't do very well on
getting it to work in multiple-inheritance scenarios, such as
create table p (f1 int check (f1>0));
creat
Robert Hodges <[EMAIL PROTECTED]> writes:
> This question may have an obvious answer I have somehow missed, but to what
> extent is locking order deterministic in PostgreSQL? For example, if
> requests from multiple transactions arrive in some deterministic order and
> acquire locks, can one assum
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Jan UrbaÅski wrote:
>> It is no longer true with the design that I planned to use. The
>> typanalyze function for the tsvector type returns an array of
>> most-frequent lexemes (cstrings actually) from the tsvectors, not an
>> array of tsvector
On Fri, May 9, 2008 at 5:37 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>> [ patch to change inherited-check-constraint behavior ]
>
> Applied after rather heavy editorializations. You didn't do very well on
> getting it to work in multiple-inheritance sce
Where are we on this?
---
Tom Dunstan wrote:
> Hi all
>
> Here is a patch that provides an initial implementation of the module
> idea that was kicked around over the last few days. While there
> certainly wasn't consensus
Added to TODO:
o Clear table counters on TRUNCATE
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php
---
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
>
Added to TODO:
o Allow an existing index to be marked as a table's primary key
---
Jonah H. Harris wrote:
> Hey all,
>
> I've run into a couple cases now where it would be helpful to easily
> assign an already-exi
Hi Tom,
First of all thanks for the quick response. No, the arrival order will not
be deterministic. Here is how we ensure determinism.
1.) SQL requests are delivered to the replication agent in a specific total
order. This could occur either because they were already serialized by a
database
Bruce Momjian wrote:
Added to TODO:
Proposed Implementation
1. Verify that the index named is a unique index
2. Check index columns for NOT NULL constraints
3. If indexed columns are not already NOT NULL, apply NOT NULL
4. If NOT NULL succeeds, complete the operation (catalogs,
dependencies, .
Tom Lane wrote:
> Jan's right: this is an oversight in the design of the VacAttrStats API.
> The existing pg_statistics "slot" types all need an array of the same
> datatype as the underlying column, but it's obvious when you think about
> it that there could be kinds of statistics that need to be
Hi,
While i'm working on a ecpg patch I found a bug in ecpg code. The simple
program above could reproduce it. But basically it crashes (segfault)
because it's trying to use a inexistent connection when we're preparing
a statement. Don't know if it deserves a ecpg_log() message. A possible
fi
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Jan's right: this is an oversight in the design of the VacAttrStats API.
> Perhaps we would also want the ability to store the base element type
> when the column is an array.
Well, that would be up to the type-specific analyze routi
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> Any comments, ideas, suggestions?
> I would add:
>5. Modify index name to use appropriate naming style.
Why, and exactly what would you define as "appropriate naming style"?
The user has always been free to pick whatever
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Now that psql '\pset format wrapped' is in CVS, we should consider when
> we want to use 'wrapped' format by default.
After experimenting for a bit, I'd say "never". This output format is
extremely ugly. Maybe if it had enough smarts not to break in th
I see that Brendan has proposed the following definition on
CommitFest:Help:
Reviewing items
If you are reviewing an item, let the other developers know by setting
the claimed parameter of the patch to your name. For example, if you
started reviewing the following patch
{{patch|[EMAIL PRO
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Bruce Momjian wrote:
Any comments, ideas, suggestions?
I would add:
5. Modify index name to use appropriate naming style.
Why, and exactly what would you define as "appropriate naming style"?
The user has always been free
On Sat, May 10, 2008 at 2:49 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I see that Brendan has proposed the following definition on
> CommitFest:Help:
>
I wouldn't say I did anything so formal as proposing a definition =)
Someone mentioned that a column to indicate who's handling each patch
would
57 matches
Mail list logo
