Hi Bruce,
Haven't looked at the code, but there's no license with it.
Andreas, are you cool with having the same License as PostgreSQL for it
(BSD license)?
:-)
Regards and best wishes,
Justin Clift
Bruce Momjian wrote:
>
> Can someone comment on this? I can't decide.
>
> ---
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have added this to the TODO list, with a question mark. Hope this is
> OK with everyone.
> o Abort SET changes made in aborted transactions (?)
Actually, I was planning to make only search_path act that way, because
of all the push-back I'd
"Rod Taylor" <[EMAIL PROTECTED]> writes:
>> 3. Isn't there a better way to find the initial dependencies? That
>> SELECT is truly ugly, and more to the point is highly likely to
>> break anytime someone rearranges the catalogs.
> I'm having a really hard time coming up with a good method for thi
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Manuel Sugawara wrote:
> Bruce Momjian <[EMAIL
> Neil Conway <[EMAIL PROTECTED]> writes:
> > I'm planning to re-implement PREPARE/EXECUTE with support only
> > for locally-prepared plans, using the existing patch as a
> > guide. The result should be a simpler patch -- once it's
> > in CVS we can worry about more advanced plan caching
> > techi
> Neil Conway <[EMAIL PROTECTED]> writes:
> > I'm planning to re-implement PREPARE/EXECUTE with support only
> > for locally-prepared plans, using the existing patch as a
> > guide. The result should be a simpler patch -- once it's
> > in CVS we can worry about more advanced plan caching
> > techi
I have added these emails to TODO.detail/prepare.
---
Karel Zak wrote:
> On Fri, Apr 12, 2002 at 12:41:34AM -0400, Neil Conway wrote:
> > On Fri, 12 Apr 2002 12:58:01 +0900
> > "Hiroshi Inoue" <[EMAIL PROTECTED]> wrote:
> >
Neil Conway <[EMAIL PROTECTED]> writes:
> I'm planning to re-implement PREPARE/EXECUTE with support only
> for locally-prepared plans, using the existing patch as a
> guide. The result should be a simpler patch -- once it's
> in CVS we can worry about more advanced plan caching
> techiques. Any co
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Mario Weilguni wrote:
> Am Donnerstag, 11. Apr
Thread added to TODO.detail/drop.
---
Christopher Kings-Lynne wrote:
> > Actually, what we need to do to reclaim space is to enable table
> > recreation without the column, now that we have relfilenode for file
> > renaming
I have added this to the TODO list, with a question mark. Hope this is
OK with everyone.
o Abort SET changes made in aborted transactions (?)
---
Tom Lane wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > I
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tatsuo Ishii wrote:
> > > I miss that case :-(. Here is the pached patch.
> > >
> > > Regards,
> > > Manuel.
> >
> > I also suggest that cclass_init() is called only if the locale is not
> > "C".
>
> OK, patch on hold while this is addressed.
Here i
Can someone comment on this feature?
---
"."@babolo.ru wrote:
> Sorry I don't know if this is right list.
>
> I use scripts of such a kind (I say "SQLbang")
>
> #!/usr/local/bin/psql -qQ
> \a \t \pset fieldsep ' '
>
> \s
Can someone comment on this? I can't decide.
---
Andreas Scherbaum wrote:
>
> Hello,
>
> i have written a module for logging changes on a table (without knowing
> the exact column names).
> Dont know where to put it, but
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > So should I go ahead and submit a patch for BETWEEN that adds SYMMETRY
> > support in the old-style code, and then at a later stage submit
> a patch that
> > makes BETWEEN a proper node?
>
> I'd prefer to do it in one step. I have not
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> So should I go ahead and submit a patch for BETWEEN that adds SYMMETRY
> support in the old-style code, and then at a later stage submit a patch that
> makes BETWEEN a proper node?
I'd prefer to do it in one step. I have not noticed any lar
Christopher Kings-Lynne wrote:
> > > So should I go ahead and submit a patch for BETWEEN that adds SYMMETRY
> > > support in the old-style code, and then at a later stage submit
> > a patch that
> > > makes BETWEEN a proper node?
> >
> > Sure, I think that makes sense. The larger BETWEEN node cod
> 3. Isn't there a better way to find the initial dependencies? That
> SELECT is truly ugly, and more to the point is highly likely to
break
> anytime someone rearranges the catalogs. I'd like to see it
generated
> automatically (maybe using a tool like findoidjoins); or perhaps we
> could do th
> > So should I go ahead and submit a patch for BETWEEN that adds SYMMETRY
> > support in the old-style code, and then at a later stage submit
> a patch that
> > makes BETWEEN a proper node?
>
> Sure, I think that makes sense. The larger BETWEEN node code will be
> tricky.
Question: Why have you
Christopher Kings-Lynne wrote:
> > TODO updated:
> >
> > > * Add BETWEEN ASYMMETRIC/SYMMETRIC (Christopher)
> > > * Christopher is Christopher Kings-Lynne <[EMAIL PROTECTED]>
>
> So should I go ahead and submit a patch for BETWEEN that adds SYMMETRY
> support in the old-style code, and then at a
> TODO updated:
>
> > * Add BETWEEN ASYMMETRIC/SYMMETRIC (Christopher)
> > * Christopher is Christopher Kings-Lynne <[EMAIL PROTECTED]>
So should I go ahead and submit a patch for BETWEEN that adds SYMMETRY
support in the old-style code, and then at a later stage submit a patch that
makes BETWEEN
TODO updated:
> * Add BETWEEN ASYMMETRIC/SYMMETRIC (Christopher)
> * Christopher is Christopher Kings-Lynne <[EMAIL PROTECTED]>
---
Christopher Kings-Lynne wrote:
> > "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>
Christopher Kings-Lynne wrote:
> Hi All,
>
> Now that Tom's modified the EXPLAIN output to appear as a query result,
> maybe SHOW and SHOW ALL should also be modified in that way. The current
> NOTICE: business is a bit messy, and it sure would assist projects just as
> pgAccess, phpPgAdmin and
Thomas Lockhart wrote:
>
> ...
> > I'm of a belief that *eventually* we really can take enough of the
> > variables into consideration for planning the best query every time. I
> > didn't say it was gunna be soon, nor easy though.
>
> I agree. But I'd like to eliminate the optimizer variability
...
> I'm of a belief that *eventually* we really can take enough of the
> variables into consideration for planning the best query every time. I
> didn't say it was gunna be soon, nor easy though.
I agree. But I'd like to eliminate the optimizer variability which
depends solely on the syntactic
Thomas Lockhart wrote:
>
> If that were exposed, then folks could have additional control over the
> optimizer no matter what syntax they prefer to use. And in fact could
> alter the behavior without having to completely rewrite their query.
>
> One could also think about a threshold mechanism
No one has replied, so I worked up a patch that I will apply in a few
days. Let me know if you don't like it.
---
Andrew Johnson wrote:
> Not sure if you're the right person to be talking to here, but the recent
> CVS pact
> Would it make sense to flatten out INNER JOINs only when the total
> number of tables involved is less than some parameter N? N
> around six or eight would probably keep the complex-query crowd
> happy, while not causing unintuitive behavior for simple queries.
> Anybody who really likes the cu
I threw together the attached program (compiles fine with gcc 2.95.2 on
Solaris 2.6 and egcs-2.91.66 on RedHat Linux 6.2) and ran it a few
times. Data is below. Usual disclaimers about hastily written code etc
:)
Machine = ghoul (generic intel, 384mb ram, dual p3-800, ide disk running
dma)
Seque
Neil Conway wrote:
> On Wed, Mar 27, 2002 at 07:56:15PM -0500, Peter Eisentraut wrote:
> > Neil Conway writes:
> >
> > > I'm curious; why is this "not the right fix"? According to the manpage:
> > >
> > > -lturns on maximum compatibility with the original
> > > AT&T lex implementation
Tatsuo Ishii wrote:
> > I miss that case :-(. Here is the pached patch.
> >
> > Regards,
> > Manuel.
>
> I also suggest that cclass_init() is called only if the locale is not
> "C".
OK, patch on hold while this is addressed.
--
Bruce Momjian| http://candle.pha.pa.us
> I miss that case :-(. Here is the pached patch.
>
> Regards,
> Manuel.
I also suggest that cclass_init() is called only if the locale is not
"C".
--
Tatsuo Ishii
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregist
> > ... I have seen many instances of when
> > PostgreSQL refuses to use an index because the data distribution is uneven.
>
> This is fixed, or at least attacked, in 7.2. Again, I do not see
> this as an argument for making the planner stupider instead of
> smarter.
Could someone fork out some
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Ulrich Neumann wrote:
> Hello everybody,
>
>
OK, previous patch removed.
This patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Manuel Sugawara w
Tom Lane wrote:
>mlw <[EMAIL PROTECTED]> writes:
>
>>That is the difference, in another post Tom said he could not get
>>excited about 10.9 second execution time over a 7.96 execution
>>time. Damn!!! I would. That is wrong.
>>
>
>Sure. Show us how to make the planner's estimates 2x more accurate
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
> > En Tue, 16 Apr 2002 19:21:50 -0400 (EDT)
> > Bruce Momjian <[EMAIL PROTECTED]> escribi?:
> >
> > > Here is a patch based on this discussion.
> >
> > I still think the xdigit class could be handled the same way the digit
> > c
On Wed, 2002-04-17 at 22:43, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > OTOH, it is also important where the file is on disk. As seen from disk
> > speed test graphs on http://www.tomshardware.com , the speed difference
> > of sequential reads is 1.5 to 2.5 between inner and o
D'Arcy J.M. Cain wrote:
> On April 17, 2002 05:44 pm, mlw wrote:
> > It took a bike ride to think about this one. The supposed advantage of a
> > sequential read over an random read, in an active multitasking system, is a
> > myth. If you are executing one query and the system is doing only that
>
On Wed, 17 Apr 2002 14:34:45 -0700
"Dann Corbit" <[EMAIL PROTECTED]> wrote:
> However, I've tentatively decided that I think the best
> way to go forward is to rewrite this code. IMHO the utility of
> plans cached in shared memory is fairly limited, but the
> code that implements this adds a lot o
mlw wrote:
> Bruce Momjian wrote:
>
> >
> > OK, yes, sequential scan _can_ be as slow as index scan, but sometimes
> > it is faster. Can you provide reasoning why index scan should be
> > preferred, other than the admin created it, which I already addressed?
>
> If you have a choice between tw
Bruce Momjian wrote:
>
> OK, yes, sequential scan _can_ be as slow as index scan, but sometimes
> it is faster. Can you provide reasoning why index scan should be
> preferred, other than the admin created it, which I already addressed?
If you have a choice between two or more sub-plans, simila
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 17, 2002 2:39 PM
To: mlw
Cc: Andrew Sullivan; PostgreSQL-development; Tom Lane
Subject: Re: [HACKERS] Index Scans become Seq Scans after VACUUM ANALYSE
mlw wrote:
> Bruce Momjian wrote:
> >
> > mlw w
[ Cc to hackers.]
I haven't see any comment on this. If no one replies, would you send
over a patch of fixes? Thanks.
---
Dmitry Tkach wrote:
> I was trying to write a gist index extension, and, after some debugging,
>
Bruce Momjian wrote:
>
> mlw wrote:
> > Bruce Momjian wrote:
> > >
> > > mlw wrote:
> > > > Now, given the choice of the two strategies on a table, both pretty close to
> > > > one another, the risk of poor performance for using the index scan is minimal
> > > > based on the statistics, but the r
Alvaro Herrera wrote:
> En Tue, 16 Apr 2002 19:21:50 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> escribi?:
>
> > Here is a patch based on this discussion.
>
> I still think the xdigit class could be handled the same way the digit
> class is (by enumeration rather than using the isxdigit func
OK, once I apply the original patch, please submit a patch for this and
people can comment on it. Thanks.
---
Alvaro Herrera wrote:
> En Tue, 16 Apr 2002 19:21:50 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> escribi?:
On April 17, 2002 05:44 pm, mlw wrote:
> It took a bike ride to think about this one. The supposed advantage of a
> sequential read over an random read, in an active multitasking system, is a
> myth. If you are executing one query and the system is doing only that
> query, you may be right.
>
> Ex
mlw <[EMAIL PROTECTED]> writes:
> It took a bike ride to think about this one. The supposed advantage of a
> sequential read over an random read, in an active multitasking system, is a
> myth.
Disagree.
> Execute a number of queries at the same time, the expected benefit of a
> sequential scan
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Bruce Momjian wrote:
> Manuel Sugawara wrote:
mlw wrote:
> Bruce Momjian wrote:
> > My second point, that index scan is more risky than sequential scan, is
> > outlined above. A sequential scan reads each page once, and uses the
> > file system read-ahead code to prefetch the disk buffers. Index scans
> > are random, and could easily re-rea
Bruce Momjian wrote:
> My second point, that index scan is more risky than sequential scan, is
> outlined above. A sequential scan reads each page once, and uses the
> file system read-ahead code to prefetch the disk buffers. Index scans
> are random, and could easily re-read disk pages to plow
Michael Loftis wrote:
> As far as the 'planner benchmark suite' so we cans tart gathering more
> statistical data about what costs should be, or are better at, that's an
> excellent idea.
People with different hardware have different random page costs,
clearly. Even different workloads affect
mlw wrote:
> Bruce Momjian wrote:
> >
> > mlw wrote:
> > > Now, given the choice of the two strategies on a table, both pretty close to
> > > one another, the risk of poor performance for using the index scan is minimal
> > > based on the statistics, but the risk of poor performance for using the
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 17, 2002 2:18 PM
To: PostgreSQL Hackers
Subject: [HACKERS] updated qCache
Hi all,
Here's an updated version of the experimental qCache patch I
posted a couple days ago (which is a port of Karel Zak's
Hi all,
Here's an updated version of the experimental qCache patch I
posted a couple days ago (which is a port of Karel Zak's 7.0
work to CVS HEAD).
Changes:
- fix segfault in EXECUTE under some circumstances (reported
by Barry Lind)
- fix some memory leaks (thanks to Karel Zak)
- write more
Bruce Momjian wrote:
>
> mlw wrote:
> > Now, given the choice of the two strategies on a table, both pretty close to
> > one another, the risk of poor performance for using the index scan is minimal
> > based on the statistics, but the risk of poor performance for using the
> > sequential scan is
mlw wrote:
> Andrew Sullivan wrote:
>
> > > Now, given the choice of the two strategies on a table, both pretty
> > > close to one another, the risk of poor performance for using the
> > > index scan is minimal based on the statistics, but the risk of poor
> > > performance for using the sequenti
Andrew Sullivan wrote:
> > Now, given the choice of the two strategies on a table, both pretty
> > close to one another, the risk of poor performance for using the
> > index scan is minimal based on the statistics, but the risk of poor
> > performance for using the sequential scan is quite high o
mlw wrote:
> Now, given the choice of the two strategies on a table, both pretty close to
> one another, the risk of poor performance for using the index scan is minimal
> based on the statistics, but the risk of poor performance for using the
> sequential scan is quite high on a large table.
Wow
On Wed, Apr 17, 2002 at 04:28:03PM -0400, mlw wrote:
> Oracle has a cost based optimizer, and they allow you to override
> it, offer hints as to what it should do, or use the rules based
> optimizer. They know that a cost based optimizer can not generate
> the best query all the time.
Oracle's t
Andrew Sullivan wrote:
> You haven't shown anything except a couple of anecdotal reports as
> evidence against his view. Anyone who asks you for more evidence
> gets treated to a remark that statistics won't do everything in this
> case.
I do not, currently, have access to systems which exhibi
The fact that an index exists adds a choice -- so by no means is the
index ignored.
But just because a Freeway exists across town doesn't make it faster
than the sideroads. It depends on the day of week, time of day, and
uncontrollable anomolies (accidents).
--
Rod Taylor
Your eyes are weary f
Tom Lane wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> >> It's one thing to say that "apples || oranges" should
> >> be interpreted as "apples::text || oranges::text", but it is quite
> >> another to say that "apples <= oranges" should be handled that way.
>
> > Hmm. istm that we might n
Does anyone know if there is a way to extract the grammar and only the
grammar from a Bison file.?
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
---(end of broadcast)---
TIP 4: Don't
Peter Eisentraut wrote:
>
> mlw writes:
>
> > Adding huristics, such as weighting for index scans, is not making the planner
> > stupider. It is making it smarter and more flexable.
>
> If life was as simple as index or no index then this might make some
> sense. But in general the planner has
Andrew Sullivan wrote:
> Given the apparent infrequency of docs-consultation, I am
> considerably less sanguine than you are about the correctness of the
> choices many DBAs make. Poking at the planner to make it use an
> index more often strikes me as at least as likely to cause worse
> performa
mlw writes:
> Adding huristics, such as weighting for index scans, is not making the planner
> stupider. It is making it smarter and more flexable.
If life was as simple as index or no index then this might make some
sense. But in general the planner has a whole bunch of choices of join
plans,
On Wed, Apr 17, 2002 at 12:35:13PM -0400, mlw wrote:
> about a 10 vs 8 second difference. I have seen many instances of when
> PostgreSQL refuses to use an index because the data distribution is uneven.
> Making it more difficult for the planer to ignore an index would solve
> practically all the
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > ... I have seen many instances of when
> > PostgreSQL refuses to use an index because the data distribution is uneven.
>
> This is fixed, or at least attacked, in 7.2. Again, I do not see this
> as an argument for making the planner stupid
mlw <[EMAIL PROTECTED]> writes:
> ... I have seen many instances of when
> PostgreSQL refuses to use an index because the data distribution is uneven.
This is fixed, or at least attacked, in 7.2. Again, I do not see this
as an argument for making the planner stupider instead of smarter.
Hannu Krosing <[EMAIL PROTECTED]> writes:
> OTOH, it is also important where the file is on disk. As seen from disk
> speed test graphs on http://www.tomshardware.com , the speed difference
> of sequential reads is 1.5 to 2.5 between inner and outer tracks.
True. But if we use the same test fil
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > On borderline conditions, wrongly using an index does not result in as bad
> > performance as wrongly not using an index,
>
> You're arguing from a completely false premise. It might be true on the
> particular cases you've looked at, but
Oliver Elphick wrote:
>On Wed, 2002-04-17 at 06:51, mlw wrote:
>
>>I just think there is sufficient evidence to suggest that if a DBA creates an
>>index, there is strong evidence (better than statistics) that the index need be
>>used. In the event that an index exists, there is a strong indicat
My opinion.
Expose some of the cost factors via run-time settings (or start-time
settings).
This would allow those who wanted to 'tweak' the planner to do so and
those that felt the defaults were fine or didn't know to leave them alone.
Comments?
---(end of broadca
I come to an idea using dblink from a contrib
directory:
Why my pl/psql function can't use common PQ stuff
to connect to other database ?
So I wrote a wrapper around PQ functions and
registered them in postgres.
Now I can write pl/psql functions
like:
CREATE OR REPLACE FUNCTION TestPQ
(
I want to change the date from a field in a tuple in a trigger_function
create table example (
my_date datetime
...
);
int na;
char select[20];
na = SPI_fnumber(trigdata->tg_relation->rd_att, "my_date");
memset(select, 0, sizeof(select));
sprintf(select, "1/1/2002");
newval = DirectF
> > On Wed, 2002-04-17 at 06:51, mlw wrote:
> > > I just think there is sufficient evidence to suggest that if a DBA
creates an
> > > index, there is strong evidence (better than statistics) that the
index need be
> > > used. In the event that an index exists, there is a strong indication
that,
78 matches
Mail list logo
