>> Actually the patch was previously rejected.
>
> Oh? Sorry, I must have missed that. On what grounds was it rejected?
Because it was decided that hyperlinks are undesirable in this place.
Instead, a simpler version of the patch was applied.
See
http://archives.postgresql.org/pgsql-hackers/2006
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
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 1
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 sayin
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 t
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:
>
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
a
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: -
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 it...By
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, si
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 Mar
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 wha
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 an
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 t
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
>
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.24&r2=1.2
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 |
> >
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
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 formali
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
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
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,
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
> > > > >happe
[ 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
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
Martijn van Oosterhout 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 the values y
> > 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 co
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 rea
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 au
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 broadcast
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)
* 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 th
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. Whic
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
>
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
"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
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
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) to
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
>
> Shou
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
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
"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 tuplesto
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
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 facto
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
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
"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 querie
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 adopte
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 imple
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 b
On Thu, 12 Oct 2006 14:17:33 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> "D'Arcy J.M. Cain" 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 definit
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 b
"D'Arcy J.M. Cain" 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 to mention
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
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 respondin
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 th
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
ex
"D'Arcy J.M. Cain" 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 imp
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 ver
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.
> 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,
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 i
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'
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 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
fe
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 th
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
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 fin
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 shou
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 {SEQ
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
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.
IST
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 getBaseTyp
[ 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 deli
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
---(
"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 versi
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. +
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
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 t
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
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 serv
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:
> >
>
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
an
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 thi
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 Postg
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 ver
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
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: http://www.sigaev.r
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 s
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 s
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 specia
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
> da
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
> 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
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:
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
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
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,
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 al
99 matches
Mail list logo
