* Andrew Sullivan:
Just because I'm one of those statistics true believers, what sort of
information do you think it is possible for the DBA to take into
consideration, when building a hint, that could not in principle be
gathered efficiently by a statistics system?
Some statistics are very
time. I find the proposed patch in pgwin32_waitforsinglesocket to be a
pretty ugly kluge though. Are you sure it's needed given the other fix?
Loop in pgwin32_send() doesn't prevent from infinite sleeping in
WaitForMultipleObjectEx in pgwin32_waitforsinglesocket. I'm not a Windows guru
at
Recently I've been playing with quite a big table (over 50mln rows),
and did some SELECT ... sum(...) WHERE ... GROUP BY ... queries.
The usual plan for these is to sort the entries according to GROUP BY
specification, then to run aggregates one by one. If the data to be
sorted is large enough,
On Wed, 2006-10-11 at 19:18 -0400, Mark Woodward wrote:
Since you're the one who wants hints, that's kind of up to you to define.
Write a specification and make a proposal.
What is the point of writing a proposal if there is a threat of will be
rejected if one of the people who would
On Thu, Oct 12, 2006 at 09:52:11AM +0200, Dawid Kuroczko wrote:
Recently I've been playing with quite a big table (over 50mln rows),
and did some SELECT ... sum(...) WHERE ... GROUP BY ... queries.
The usual plan for these is to sort the entries according to GROUP BY
specification, then to
Attached patch implements that idea.
May be that way (untested):
if ( isUDP (what FP_WRITE) )
for(;;) {
r = WaitForMultipleObjects(100 ms);
if ( r == WAIT_TIMEOUT ) {
r == WSASend( sero packet ); /* see comments in pgwin32_select()
*/
[ analyze result of WSASend:
Clinging to sanity, [EMAIL PROTECTED] (Mark Woodward) mumbled into
her beard:
What is the point of writing a proposal if there is a threat of
will be rejected if one of the people who would do the rejection
doesn't at least outline what would be acceptable?
If your proposal is merely let's
On Wed, Oct 11, 2006 at 06:26:50PM -0400, Bruce Momjian wrote:
Funny, sounds like what I usually do. I welcome the assistance.
Well, yes, that was my impression too. The complaint in the thread
that started all this, as I understood it, was that there were big,
hairy features that tended to
On Wed, Oct 11, 2006 at 03:08:42PM -0700, Ron Mayer wrote:
Is one example is the table of addresses clustered by zip-code
and indexes on State, City, County, etc?
No.
Now I'm not saying that a more advanced statistics system
couldn't one-day be written that sees these patterns in the
data
On Thu, Oct 12, 2006 at 08:34:45AM +0200, Florian Weimer wrote:
Some statistics are very hard to gather from a sample, e.g. the number
of distinct values in a column.
Then how can the DBA know it, either? The problem with this sort of
argument is always that people are claiming some special
1)
# create temp table a ( a int ) without oids on commit delete rows;
# insert into a values(1);
# begin;
# insert into a values(2);
# commit;
# select * from a;
a
---
(0 rows)
2)
# insert into a values(1);
# begin;
# insert into a values(2);
# rollback;
# select * from a;
a
---
(0 rows)
It
Teodor Sigaev wrote:
2)
# insert into a values(1);
You're running in auto-commit, mode. An implicit commit happens after
this statement. Which clears the table.
# begin;
# insert into a values(2);
# rollback;
# select * from a;
a
---
(0 rows)
It seems to me that 1) is good, but 2) makes
You're running in auto-commit, mode. An implicit commit happens after
this statement. Which clears the table.
Looks right to me.
Oops, I see
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW:
Simon Riggs [EMAIL PROTECTED] writes:
The *right* place, IMHO, for planner information is to decorate the
tables, columns and relationships so that *every* SQL statement can pick
that up. If the world changes, you make one change and all your SQL
benefits. As the analyzers improve, you may
On Thu, Oct 12, 2006 at 08:50:04AM -0400, Greg Stark wrote:
Not to say this isn't a good idea -- i think it's a great idea. But note that
it doesn't solve some of the use cases of hints. Consider something like:
WHERE NOT radius_authenticate(suspected_hacker)
or
WHERE NOT
On Thu, Oct 12, 2006 at 07:14:36AM -0400, Andrew Sullivan wrote:
On Wed, Oct 11, 2006 at 06:26:50PM -0400, Bruce Momjian wrote:
Funny, sounds like what I usually do. I welcome the assistance.
Well, yes, that was my impression too. The complaint in the thread
that started all this, as I
Mark Woodward wrote:
Exactly. IMHO, it is a frustrating environment. PostgreSQL is a great
system, and while I completely respect the individuals involved, I think
the management for lack of a better term, is difficult.
'course you're welcome to fork the project as well if your style
and/or
On Thu, 2006-10-12 at 15:06 +0200, Martijn van Oosterhout wrote:
On Thu, Oct 12, 2006 at 08:50:04AM -0400, Greg Stark wrote:
Not to say this isn't a good idea -- i think it's a great idea. But note
that
it doesn't solve some of the use cases of hints. Consider something like:
WHERE
On Thu, Oct 12, 2006 at 12:19:07AM -0400, Ye Qin wrote:
I tried to use O_DIRECT on Linux (SuSe) Kernel 2.6, but failed to make it
run.
For example, if I added the option in the open of BasicOpenFile(),
I got the following error after typing psql -l,
psql: could not connect to server:
On 10/12/06, Marco Serantoni [EMAIL PROTECTED] wrote:
I'm evaluating of use postgresql but for local law requirements is
needed for the access of some kind of data (sensitive) a log of the
accesses (Auditing) is a feature available in many databases but i've
seen that lacks in PostgreSQL,
On Thu, Oct 12, 2006 at 02:25:29PM +0100, Simon Riggs wrote:
The CREATE OPERATOR command already has a RESTRICT=res_proc clause which
provides the ability to attach selectivity functions onto an operator.
So this is already possible if you turn radius_authenticate() into an
operator. The
Jim C. Nasby wrote:
On Thu, Oct 12, 2006 at 07:14:36AM -0400, Andrew Sullivan wrote:
On Wed, Oct 11, 2006 at 06:26:50PM -0400, Bruce Momjian wrote:
Funny, sounds like what I usually do. I welcome the assistance.
Well, yes, that was my impression too. The complaint in the thread
Andrew Sullivan wrote:
On Wed, Oct 11, 2006 at 06:26:50PM -0400, Bruce Momjian wrote:
Funny, sounds like what I usually do. I welcome the assistance.
Well, yes, that was my impression too. The complaint in the thread
that started all this, as I understood it, was that there were big,
FYI, I have started working on a replication section for our 8.2
documentation. I will post a draft copy as soon as I finish.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Hiroshi Saito [EMAIL PROTECTED] writes:
I have warning with MinGW
qsort.c:53:1: warning: min redefined
I've fixed this by using Min() from c.h instead.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions
Hi Tom-san.
From: Tom Lane
Hiroshi Saito [EMAIL PROTECTED] writes:
I have warning with MinGW
qsort.c:53:1: warning: min redefined
I've fixed this by using Min() from c.h instead.
Ahh, I was consideration shortage.
Thanks!!
Regards,
Hiroshi Saito
---(end of
I'm trying to create a few new types, and based on the type in/out
functions will operate a bit differently.
For the input function finding the type Oid is easy -
Oid our_type_oid = PG_GETARG_OID(1);
For output though I'm having difficulty finding out the type Oid.
I've tried using
While investigating Merlin's bug report here:
http://archives.postgresql.org/pgsql-general/2006-10/msg00447.php
I realized that we've completely failed to consider the interactions
of $subject. In particular, functions.c still thinks that SELECT is
the only type of query that can return rows.
Mark,
That is sort of the stopping block. None of us know what it should look
like, but leaving the topic as if you want it, go do the work and submit
a patch. Isn't going to get it done.
First we should decide if it is, in fact, something that ought to happen,
then if that happens, we should
Weslee Bilodeau [EMAIL PROTECTED] writes:
I'm trying to create a few new types, and based on the type in/out
functions will operate a bit differently.
For the input function finding the type Oid is easy -
Oid our_type_oid = PG_GETARG_OID(1);
For output though I'm having difficulty finding
[ This is off-topic for -performance, please continue the thread in
-hackers ]
Jim C. Nasby [EMAIL PROTECTED] writes:
These hints would outright force the planner to do things a certain way.
... FROM table /* ACCESS {SEQSCAN | [[NO] BITMAP] INDEX index_name} */
This proposal seems to
On 10/12/06, Tom Lane [EMAIL PROTECTED] wrote:
[ This is off-topic for -performance, please continue the thread in
-hackers ]
This proposal seems to deliberately ignore every point that has been
made *against* doing things that way. It doesn't separate the hints
from the queries, it doesn't
On Thu, Oct 12, 2006 at 11:42:32AM -0400, Tom Lane wrote:
[ This is off-topic for -performance, please continue the thread in
-hackers ]
Jim C. Nasby [EMAIL PROTECTED] writes:
These hints would outright force the planner to do things a certain way.
... FROM table /* ACCESS {SEQSCAN |
OK, I just have to comment...
Jim C. Nasby [EMAIL PROTECTED] writes:
These hints would outright force the planner to do things a certain way.
... FROM table /* ACCESS {SEQSCAN | [[NO] BITMAP] INDEX index_name} */
This proposal seems to deliberately ignore every point that has been
made
On Thu, 28 Sep 2006 23:23:30 -0400
Tom Lane [EMAIL PROTECTED] wrote:
The existing type is depricated and has been since at least 8.1; so yes,
it's slated for removal.
Well, my perception of that has always been it needs to be upgraded or
removed. So if D'Arcy wants to work on the
Jim C. Nasby [EMAIL PROTECTED] writes:
Yes, but as I mentioned the idea here was to come up with something that
is (hopefully) easy to define and implement. In other words, something
that should be doable for 8.3.
Sorry, but that is not anywhere on my list of criteria for an important
feature.
Jim,
These hints would outright force the planner to do things a certain way.
... FROM table /* ACCESS {SEQSCAN | [[NO] BITMAP] INDEX index_name} */
This proposal seems to deliberately ignore every point that has been
made *against* doing things that way. It doesn't separate the hints
from
Tom Lane wrote:
Weslee Bilodeau [EMAIL PROTECTED] writes:
I'm trying to create a few new types, and based on the type in/out
functions will operate a bit differently.
For the input function finding the type Oid is easy -
Oid our_type_oid = PG_GETARG_OID(1);
For output though I'm having
Csaba,
I guess the angle is: I, as a practicing DBA would like to be able to
experiment and get most out of the imperfect tool I have, and you, the
developers, want to make the tool perfect... I don't care about perfect
tools, it just have to do the job... hints or anything else, if I can
make
Weslee Bilodeau [EMAIL PROTECTED] writes:
It works perfectly so long as I used the same key for all my custom
types. When I want a different key for each type though (so for example,
encrypt credit cards with one key, addresses with another, etc) I need a
way to tell them apart.
[ shrug... ]
D'Arcy J.M. Cain darcy@druid.net writes:
Tom Lane [EMAIL PROTECTED] wrote:
Well, my perception of that has always been it needs to be upgraded or
removed. So if D'Arcy wants to work on the improvement angle, I have
no problem with him doing so. The thing we need to negotiate is how
much
On Thu, Oct 12, 2006 at 11:25:25AM -0500, Jim C. Nasby wrote:
Yes, but it does one key thing: allows DBAs to fix problems *NOW*. See
also my comment below.
If I may argue in the other direction, speaking as one whose career
(if we may be generous enough to call it that) has been pretty much
On Thu, Oct 12, 2006 at 10:20:43AM -0400, Bruce Momjian wrote:
use a wiki to track open development items, with some status, like I did
for the open items list for 8.2. I usually only do that during feature
freeze, but could expand it and open it up for others to edit.
So do I understand this
On Thu, 12 Oct 2006 13:21:37 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Well, the patch I submitted is definitely an improvement over the
existing version. Are you saying that I have to make further
improvements before these ones can be imported?
I didn't say that. I was responding to
D'Arcy J.M. Cain darcy@druid.net writes:
Cool. So what do I do with the patch? Should I add the currency
symbol back in and commit or should I resubmit the patch to hackers for
further review?
Well, one thing you definitely *don't* do is commit right now, because
we're in feature freeze, not
On 10/12/06, Andrew Sullivan [EMAIL PROTECTED] wrote:
On Thu, Oct 12, 2006 at 11:25:25AM -0500, Jim C. Nasby wrote:
Yes, but it does one key thing: allows DBAs to fix problems *NOW*. See
also my comment below.
If I may argue in the other direction, speaking as one whose career
(if we may be
On Thu, 12 Oct 2006 14:17:33 -0400
Tom Lane [EMAIL PROTECTED] wrote:
D'Arcy J.M. Cain darcy@druid.net writes:
Cool. So what do I do with the patch? Should I add the currency
symbol back in and commit or should I resubmit the patch to hackers for
further review?
Well, one thing you
On Thu, Oct 12, 2006 at 12:19:24PM -0400, Tom Lane wrote:
I think the most promising answer may be to push RETURNING rows into a
TupleStore and then read them out from there, which is pretty much the
same approach we adopted for RETURNING queries inside portals. This'd
allow the query to be
On 10/12/06, Tom Lane [EMAIL PROTECTED] wrote:
I think the most promising answer may be to push RETURNING rows into a
TupleStore and then read them out from there, which is pretty much the
same approach we adopted for RETURNING queries inside portals.
It certainly sounds like the safest
On Thu, Oct 12, 2006 at 01:28:18PM -0500, Jim C. Nasby wrote:
On Thu, Oct 12, 2006 at 12:19:24PM -0400, Tom Lane wrote:
I think the most promising answer may be to push RETURNING rows
into a TupleStore and then read them out from there, which is
pretty much the same approach we adopted for
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Oct 12, 2006 at 12:19:24PM -0400, Tom Lane wrote:
I think the most promising answer may be to push RETURNING rows into a
TupleStore and then read them out from there, which is pretty much the
same approach we adopted for RETURNING queries inside
On Thu, Oct 12, 2006 at 01:53:27PM -0400, Andrew Sullivan wrote:
On Thu, Oct 12, 2006 at 10:20:43AM -0400, Bruce Momjian wrote:
use a wiki to track open development items, with some status, like I did
for the open items list for 8.2. I usually only do that during feature
freeze, but could
On Thu, Oct 12, 2006 at 02:50:34PM -0400, Tom Lane wrote:
ISTM that pushing to a tuplestore is a lot of extra work for
I'm not entirely convinced of that --- the overhead of getting down
through functions.c and ExecutorRun into the per-tuple loop isn't
trivial either. It wouldn't work at
David Fetter [EMAIL PROTECTED] writes:
More generally, would this change impede promoting RETURNING to work
just as VALUES does in 8.2 (i.e. being able to join RETURNING results,
etc.)?
Making that happen would imply a whole lot of other changes; this issue
isn't the principal gating factor.
On Thu, Oct 12, 2006 at 03:51:39PM +0400, Teodor Sigaev wrote:
You're running in auto-commit, mode. An implicit commit happens
after this statement. Which clears the table. Looks right to me.
Oops, I see
Should something notice and raise a warning when people create a TEMP
table and have
Jim C. Nasby [EMAIL PROTECTED] writes:
The specific concern I have is large result sets, like 10s or 100s of MB
(or more). We just added support for not buffering those in psql, so it
seems like a step backwards to have the backend now buffering it (unless
I'm confused on how a tuplestore
On Thu, Oct 12, 2006 at 03:03:43PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
The specific concern I have is large result sets, like 10s or 100s of MB
(or more). We just added support for not buffering those in psql, so it
seems like a step backwards to have the backend
On Thu, Oct 12, 2006 at 12:01:12PM -0700, David Fetter wrote:
On Thu, Oct 12, 2006 at 03:51:39PM +0400, Teodor Sigaev wrote:
You're running in auto-commit, mode. An implicit commit happens
after this statement. Which clears the table. Looks right to me.
Oops, I see
Should something
On Thu, Oct 12, 2006 at 01:56:37PM -0500, Jim C. Nasby wrote:
*ahem* nudge people to update the status of what they're working on once
a month.
Well, though, remember that the point of this was supposed to be to
make things easier for the developers, who are already spending (it
would seem) too
Neil Conway wrote:
On Mon, 2006-09-04 at 10:23 +0200, Albe Laurenz wrote:
This is just a 'one line' change in the documentation of
the --with-ldap flag of ./configure
Applied, thanks for the patch.
(BTW, when trivial patches like this fall through the cracks, I'd
encourage patch
Jim C. Nasby [EMAIL PROTECTED] writes:
Sure, it's just a lot of data to be shuffling around if we can avoid it.
Perhaps we could only do this if there's triggers on the table involved?
Maybe, but it's awfully late in the 8.2 cycle to be worrying about
performance improvements for something that
On Thu, 2006-10-12 at 21:11 +0200, Peter Eisentraut wrote:
Actually the patch was previously rejected.
Oh? Sorry, I must have missed that. On what grounds was it rejected?
-Neil
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Thu, Oct 12, 2006 at 02:07:28PM -0500, Jim C. Nasby wrote:
On Thu, Oct 12, 2006 at 12:01:12PM -0700, David Fetter wrote:
On Thu, Oct 12, 2006 at 03:51:39PM +0400, Teodor Sigaev wrote:
You're running in auto-commit, mode. An implicit commit
happens after this statement. Which clears
Stephen Frost [EMAIL PROTECTED] writes:
* Neil Conway ([EMAIL PROTECTED]) wrote:
There is no guarantee why SQL NULL and PG_RETURN_XYZ(NULL) refer to the
same thing -- use PG_RETURN_NULL() to return a SQL NULL value, or just
make the function strict.
Huh, alright. I'll probably just change
Hmmm, if you already understand Visual Basic syntax, should we support
that too? Or maybe we should support MySQL's use of '-00-00' as the
zero date because people understand that?
You completely misunderstood me... I have no idea about oracle hints,
never used Oracle in fact. My
Csaba Nagy [EMAIL PROTECTED] writes:
Until that point is achieved, the above proposal is one of the simplest
to understand for the tweaking DBA, and the fastest to deploy when faced
with catastrophic plans. And I would guess it is one of the simplest to
be implemented and probably not very
On Thu, Oct 12, 2006 at 02:21:55PM -0400, Merlin Moncure wrote:
third way: to solve the problem of data (especially constants) not
being available to the planner at the time the plan was generated.
this happens most often with prepared statements and sql udfs. note
that changes to the plan
On Thu, Oct 12, 2006 at 09:40:30AM -0700, Josh Berkus wrote:
Jim,
These hints would outright force the planner to do things a certain way.
... FROM table /* ACCESS {SEQSCAN | [[NO] BITMAP] INDEX index_name} */
This proposal seems to deliberately ignore every point that has been
made
* Tom Lane ([EMAIL PROTECTED]) wrote:
(However, now that we support nulls in arrays, meseems a more consistent
definition would be that it allows null inputs and just includes them in
the output. So probably you do need it non-strict.)
This was my intention.
I'm inclined to think that this
Wasn't configure changed to complain if it's fed a bogus argument? I
just did ./configure --with-deps on a fresh checkout and it didn't
complain...
--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Jim C. Nasby wrote:
Wasn't configure changed to complain if it's fed a bogus argument? I
just did ./configure --with-deps on a fresh checkout and it didn't
complain...
My recollection was Peter said this was an autoconf feature.
cheers
andrew
---(end of
On Thu, Oct 12, 2006 at 04:41:14PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
Wasn't configure changed to complain if it's fed a bogus argument? I
just did ./configure --with-deps on a fresh checkout and it didn't
complain...
My recollection was Peter said this was an autoconf
Jim,
I don't see how adding extra tags to queries is easier to implement
than an ability to modify the system catalogs. Quite the opposite,
really.
And, as I said, if you're going to push for a feature that will be
obsolesced in one version, then you're going to have a really rocky
Well, one nice thing about the per-query method is you can post
before
and after EXPLAIN ANALYZE along with the hints.
One bad thing is that application designers will tend to use the hint,
fix
the immediate issue, and never report a problem at all. And query
hints
would not be
Martijn van Oosterhout kleptog@svana.org writes:
Which could then be used by the planner. Or more directly:
CREATE HISTOGRAM FOR FUNCTION verify_pk_signature(documenent)
AS ( true = 99, false = 1 );
(Perhaps DECLARE is the better phrase?).
Except that the distribution is a property of
Andrew Sullivan wrote:
On Thu, Oct 12, 2006 at 01:56:37PM -0500, Jim C. Nasby wrote:
*ahem* nudge people to update the status of what they're working on once
a month.
Well, though, remember that the point of this was supposed to be to
make things easier for the developers, who are already
[ trying once again to push this thread over to -hackers where it belongs ]
Arjen van der Meijden [EMAIL PROTECTED] writes:
On 12-10-2006 21:07 Jeff Davis wrote:
On Thu, 2006-10-12 at 19:15 +0200, Csaba Nagy wrote:
To formalize the proposal a litte, you could have syntax like:
CREATE HINT
David Fetter wrote:
On Thu, Oct 12, 2006 at 02:07:28PM -0500, Jim C. Nasby wrote:
On Thu, Oct 12, 2006 at 12:01:12PM -0700, David Fetter wrote:
On Thu, Oct 12, 2006 at 03:51:39PM +0400, Teodor Sigaev wrote:
You're running in auto-commit, mode. An implicit commit
happens after this
Bucky Jordan wrote:
What about using regular expressions, plus, if you have a function
(views, or any other statement that is stored), you can assign a rule to
that particular function. So you get matching, plus explicit selection.
This way it's easy to find all your hints, turn them off,
This thread has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
D'Arcy J.M. Cain wrote:
On Thu, 12 Oct 2006 14:17:33 -0400
Tom Lane [EMAIL PROTECTED] wrote:
D'Arcy J.M.
I wrote:
ISTM that ideally, a query with RETURNING ought to act like a SELECT
for the purposes of a SQL function --- to wit, that the result rows are
discarded if it's not the last query in the function, and are returned
as the function result if it is.
The current state of affairs is that
On Thu, 2006-10-12 at 17:28 -0400, Tom Lane wrote:
[ trying once again to push this thread over to -hackers where it belongs ]
Arjen van der Meijden [EMAIL PROTECTED] writes:
On 12-10-2006 21:07 Jeff Davis wrote:
On Thu, 2006-10-12 at 19:15 +0200, Csaba Nagy wrote:
To formalize the
Bruce Momjian [EMAIL PROTECTED] writes:
David Fetter wrote:
Should something notice and raise a warning when people create a
TEMP table and have AUTOCOMMIT on?
Added to TODO:
o Issue a notice if CREATE TABLE ... ON COMMIT { DELETE ROWS |
DROP } is issued outside a
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
David Fetter wrote:
Should something notice and raise a warning when people create a
TEMP table and have AUTOCOMMIT on?
Added to TODO:
o Issue a notice if CREATE TABLE ... ON COMMIT { DELETE ROWS |
DROP } is
Tom Lane wrote:
Log Message:
---
Stamp 7.3.16.
Tags:
REL7_3_STABLE
Modified Files:
--
pgsql:
configure.in (r1.217.2.24 - r1.217.2.25)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/configure.in.diff?r1=1.217.2.24r2=1.217.2.25)
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Thu, Oct 12, 2006 at 04:41:14PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
Wasn't configure changed to complain if it's fed a bogus argument? I
just did ./configure --with-deps on a fresh checkout and it didn't
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Stamp 7.3.16.
Uh, I thought only Marc was supposed to do that before packaging? I was
skipping it.
I've done it the last few times for back-branch releases --- I was under
the impression that Marc didn't have an installed copy anymore
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Stamp 7.3.16.
Uh, I thought only Marc was supposed to do that before packaging? I was
skipping it.
I've done it the last few times for back-branch releases --- I was under
the impression that Marc didn't have
Bruce Momjian [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
IIRC it was made a non-fatal warning somewhere near the end of the
output, but I'm not sure...
It spits out this line just before it creates its output files:
*** Option ignored: --with-lkjasdf
Of course, since it
Tom, Hi. Sorry that i can't response your message soon... i lost my internet connection...But you were right... I forgot to modify the relnatts of the pg_class table in DATA line for it... that was crashing the initdb command
Thanks... if you don't remind me of that, i would never see
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
IIRC it was made a non-fatal warning somewhere near the end of the
output, but I'm not sure...
It spits out this line just before it creates its output files:
*** Option ignored: --with-lkjasdf
On Oct 12, 2006, at 4:26 AM, Andrew Sullivan wrote:
On Thu, Oct 12, 2006 at 08:34:45AM +0200, Florian Weimer wrote:
Some statistics are very hard to gather from a sample, e.g. the
number
of distinct values in a column.
Then how can the DBA know it, either? The problem with this sort of
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
IIRC it was made a non-fatal warning somewhere near the end of the
output, but I'm not sure...
It spits out this line just before it creates its output files:
*** Option
Casey Duncan [EMAIL PROTECTED] writes:
Yes, but it may be much more efficient for the human to tell the
computer than for the computer to introspect things. Take, for
example, ndisinct as data grows large.
Yeah, an override estimate for a column's ndistinct seems a perfect
example of the
Stephen Frost [EMAIL PROTECTED] writes:
Another alternative would be to provide a seperate area for each
aggregate to put any other information it needs.
I'm not convinced that that's necessary --- the cases we have at hand
suggest that the transition function is perfectly capable of doing the
I wrote:
aggregate_state would have no other uses in the system, and its input
and output functions would raise an error, so type safety is assured
--- there would be no way to call either the sfunc or ffunc manually,
except by passing a NULL value, which should be safe because that's what
Tom Lane wrote:
We have also talked about solving the multi-column statistics problem
(which, at its core, is which combinations of columns are worth
accumulating stats for? --- you can't possibly store stats for every
combination!) by having what would amount to hints from the DBA saying
Quoth [EMAIL PROTECTED] (Jeff Davis):
On Thu, 2006-10-12 at 17:28 -0400, Tom Lane wrote:
[ trying once again to push this thread over to -hackers where it belongs ]
Arjen van der Meijden [EMAIL PROTECTED] writes:
On 12-10-2006 21:07 Jeff Davis wrote:
On Thu, 2006-10-12 at 19:15 +0200,
Tom,
Can you please suggest a good practice how to propagate such DB
settings into dumps?
I also suffer from this: my DB currently have 5 schemas and
application strongly depends on the search_path. I cannot dump whole
cluster, I need only 1 specific database. At this moment I use ugly
solution
99 matches
Mail list logo
