> Hi,
> i want to add support for exceptions that are
> supported in oracle, in plpgsql.
>
> mainly i am want to add custome exceptions support in
> plpgsql. like in Oracle we use
> EXCEPTION myexp
>
> can any body help me.
Hello
http://developer.postgresql.org/docs/postgres/plpgsql-control-
Harald Fuchs <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> One possible approach is to do the invalidation on a sufficiently coarse
>> grain that we don't care. For example, I would be inclined to make any
>> change in a table's schema invalidate all plans that use that tab
Hi,
i want to add support for exceptions that are
supported in oracle, in plpgsql.
mainly i am want to add custome exceptions support in
plpgsql. like in Oracle we use
EXCEPTION myexp
can any body help me.
Regards,
Asif Ali.
__
Do You Yahoo!?
T
(BTom Lane wrote:
(B> I'd view this as a postmaster state that propagates to backends.
(B> Probably you'd enable it by means of a postmaster option, and the
(B> only way to get out of it is to shut down and restart the postmaster
(B> without the option.
(B
(BI've created a patch to make a p
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
O.k. I got 7.3.9 to operate as expected on FC2 (64bit) and these are my
results:
enable_hashagg on:
HashAggregate (cost=80.00..82.50 rows=1000 width=404) (actual
time=209.746..209.750 rows=1 loops=1)
You got co
"Tom Lane" <[EMAIL PROTECTED]> writes
> So it'll get an error ... this scenario doesn't strike me as any worse
> than any other problem occuring in post-commit cleanup. The locks left
> around by the not-cleaned-up transaction would probably be a bigger
> issue, for example.
Yes, the result is a
Tom Lane wrote:
...
I think the reason this is popping to the top of the runtime is that the
joins are so wide (an average of ~85 columns in a join tuple according
to the numbers above). Because there are lots of variable-width columns
involved, most of the time the fast path for field access does
Miroslav Šulc wrote:
Tom Lane wrote:
...
I think the reason this is popping to the top of the runtime is that the
joins are so wide (an average of ~85 columns in a join tuple according
to the numbers above). Because there are lots of variable-width columns
involved, most of the time the fast path
Tom Lane wrote:
I wrote:
Since ExecProject operations within a nest of joins are going to be
dealing entirely with Vars, I wonder if we couldn't speed matters up
by having a short-circuit case for a projection that is only Vars.
Essentially it would be a lot like execJunk.c, except able to cope
Tom Lane wrote:
=?windows-1250?Q?Miroslav_=8Aulc?= <[EMAIL PROTECTED]> writes:
As there are a lot of varchar(1) in the AdDevicesSites table, wouldn't
be helpful to change them to char(1)? Would it solve the variable-width
problem at least for some fields and speed the query up?
No, becaus
Tom Lane wrote:
So I have some results. I have tested the query on both PostgreSQL 8.0.1
and MySQL 4.1.8 with LIMIT set to 30 and OFFSET set to 6000. PostgreSQL
result is 11,667.916 ms, MySQL result is 448.4 ms.
That's a fairly impressive discrepancy :-(, and even the slot_getattr()
patch th
In article <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> writes:
> One possible approach is to do the invalidation on a sufficiently coarse
> grain that we don't care. For example, I would be inclined to make any
> change in a table's schema invalidate all plans that use that table at
> all;
On my machine (Laptop with Pentium-M 1.6 GHz and 512MB DDR333) I get the
following timings :
Big Joins Query will all the fields and no order by (I just put a SELECT
* in the first table) yielding about 6k rows :
=> 12136.338 ms
Replacing the SELECT * from the table with many fields by ju
I have asked him for the data and played with his queries, and obtained
massive speedups with the following queries :
http://boutiquenumerique.com/pf/miroslav/query.sql
http://boutiquenumerique.com/pf/miroslav/query2.sql
http://boutiquenumerique.com/pf/miroslav/materialize.sql
Note that my opt
Tom Lane wrote:
=?windows-1250?Q?Miroslav_=8Aulc?= <[EMAIL PROTECTED]> writes:
seriously, I am far below this level of knowledge. But I can contribute
a test that (maybe) can help. I have rewritten the query so it JOINs the
varchar() fields (in fact all fields except the IDPK) at the last INNE
The problem that persists with this is that it throws in extra
processing at the time that the system is the _most_ busy doing
updates, thereby worsening latency at times when the system may
already be reeling at the load.
I think, as a result, that VACUUM will _have_ to be done
asynchronously.
W
[EMAIL PROTECTED] (Rod Taylor) wrote:
> It's a fairly limited case and by no means removes the requirement for
> regular vacuums, but for an update heavy structure perhaps it would be
> worth while? Even if it could only keep indexes clean it would help.
The problem that persists with this is that
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> What if AtEOXact_Inval() fails (though the chance is slim)? Does that mean
> that smgrDoPendingDeletes() -> DropRelFileNodeBuffers can never get
> executed, which means we can never "dropped without write" the buffers
> belonging to the victim relation?
On postgresql-8.0.0 I've faced a *really* weird behavior.
A simple query (single table - simple function call - no index),
makes postgres process grow about as much as the memory size required
to keep ALL rows in memory.
The invoked procedure call doesn't leak.
It's IMMUTABLE.
Calls other procedu
On Wed, Mar 16, 2005 at 11:20:12PM -0500, Bruce Momjian wrote:
>
> Basically we do open_datasync -> fdatasync -> fsync. This is
> empirically what we found to be fastest on most operating systems, and
> we default to the first one that exists on the operating system.
>
> Notice we never default
One of the RBL lists you (Bruno and Tom) use seems to be poorly maintained. My
new IP address is listed in their database as a dynamic address (it's not, it
even reverse resolves). I've notified this list multiple times that this IP
address is listed improperly and never received any reply. RBL li
"Tom Lane" <[EMAIL PROTECTED]> writes
> It strikes me that the FlushRelationBuffers call is unnecessary and
> causes useless I/O, namely writing out pages into a file that's
> about to be deleted anyway. If we simply removed it then any buffers
> belonging to the victim relation would stay in mem
"Tom Lane" <[EMAIL PROTECTED]> writes
> If your objection is that it's not being maintained, then that is no
> solution. Once it's out of the source code CVS it is *guaranteed* to
> not get updated to track source-code changes.
>
Is it possible that we insert some tags (like doc++ does) into sou
Neil Conway <[EMAIL PROTECTED]> writes:
> Here's one idea to fix this: when planning a Query, transform the Query
> into a "PlannedQuery". This would essentially be the same as the
> QueryState we discussed earlier, except that we would also walk through
> the Query and adjust references to nest
Tom Lane wrote:
That's a bit nasty. I'm fairly sure that I added in_info_list to the
walker recursion because I had to; I don't recall the exact scenario,
but I think it needs to be possible to reassign relation numbers
within that data structure if we are doing it elsewhere in a query
tree.
It wa
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> O.k. I got 7.3.9 to operate as expected on FC2 (64bit) and these are my
> results:
> enable_hashagg on:
> HashAggregate (cost=80.00..82.50 rows=1000 width=404) (actual
> time=209.746..209.750 rows=1 loops=1)
You got confused somewhere along the
Shachar Shemesh wrote:
To summarize, just give me read only access to the old project's data
and I'm set.
I second that.
- thomas
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Marc G. Fournier wrote:
On Sun, 20 Mar 2005, Thomas Hallgren wrote:
Marc G. Fournier wrote:
Once I've copied both over, I'll get Chris to mark the gborg project
as being 'disabled' so that nobody will see it over there anymore ...
Ok, I submitted a request for the project under pgfoundry. Same na
I think having to be on a specific server to get automatic updates on
the front page is the problem. Moving it not the correct solution. There
are may postgresql related projects that don't live on pgfoundry, or
even gborg.
Why is this a necessity?
Can't we set up some sort of interface to the
On Sun, 20 Mar 2005, Thomas Hallgren wrote:
Marc G. Fournier wrote:
If only the CVS/Mailing lists are needed, and nothing that is "in the
database", then this shouldn't be too hard ... go to pgfoundry, submit for
the new project ... once it is approved, create the various mailing lists
that you
Marc G. Fournier wrote:
If only the CVS/Mailing lists are needed, and nothing that is "in the
database", then this shouldn't be too hard ... go to pgfoundry, submit
for the new project ... once it is approved, create the various mailing
lists that you have on gborg, and then, *before* you do any
On 7.4 and up you may have to set enable_hashagg = off to force a
Sort/GroupAggregate plan instead of HashAggregate.
O.k. on FC2 7.4.6 64bit I get:
-
HashAggregate (cost=80.00..82.50 rows=
After some further digging, I think we have 3 problems.
1. On Windows gettext wants to hijack printf and friends, as below. This
strikes me as rather unfriendly behaviour by a library header file.
Anyway, mercifully libintl.h is included in our source in exactly one
spot, so I think the thing to
Robert Treat <[EMAIL PROTECTED]> writes:
> I'm currently working on consolidating some of the content on the developer
> site with the current web code cvs and am wondering what to do with
> http://developer.postgresql.org/docs/pgsql/src/tools/backend/index.html.
> This link actually comes righ
If only the CVS/Mailing lists are needed, and nothing that is "in the
database", then this shouldn't be too hard ... go to pgfoundry, submit for
the new project ... once it is approved, create the various mailing lists
that you have on gborg, and then, *before* you do anything else on either,
I
I'm currently working on consolidating some of the content on the developer
site with the current web code cvs and am wondering what to do with
http://developer.postgresql.org/docs/pgsql/src/tools/backend/index.html.
This link actually comes right out of the postgresql sources, but it is
actua
Markus Bertheau <[EMAIL PROTECTED]> writes:
>> It's already true that the individual buffers, as opposed to the buffer
>> descriptors, are allocated only as needed; which makes the overhead
>> of a large local_buffers setting pretty small if you don't actually do
>> much with temp tables in a given
Neil Conway <[EMAIL PROTECTED]> writes:
> I've got most of this finished; I'll post a patch soon. One issue I ran
> into is how to handle query_tree_mutator() and query_tree_walker(): they
> both expect to be able to traverse a Query's in_info_list, which my
> patch moves into the QueryState str
Simon Riggs <[EMAIL PROTECTED]> writes:
> ISTM that buffers belonging to the victim relation would not necessarily
> stay in memory.
Right. They'd be unpinned and therefore candidates for being written
out and recycled. So we *might* write them before they are dropped.
That's still better than *
--On Samstag, März 19, 2005 11:05:39 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Jaime Casanova <[EMAIL PROTECTED]> writes:
On Fri, 18 Mar 2005 23:31:26 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
Why do you not define the problem as "when we decide a view is
updateable and create the needed rules f
On Sat, 2005-03-19 at 18:53 -0500, Tom Lane wrote:
> Currently, in places like heap_drop_with_catalog, we issue a
> FlushRelationBuffers() call followed by smgrscheduleunlink().
> The latter doesn't actually do anything right away, but schedules
> a file unlink to occur after transaction commit.
>
On Sat, 2005-03-19 at 12:57 -0500, Tom Lane wrote:
> That means we can go ahead with providing a GUC variable to make the
> array size user-selectable. I was thinking of calling it either
> "local_buffers" (in contrast to "shared_buffers") or "temp_buffers"
> (to emphasize the fact that they're us
Markus Bertheau wrote:
-- Start of PGP signed section.
> ? ???, 19/03/2005 ? 12:57 -0500, Tom Lane ?:
>
> > It's already true that the individual buffers, as opposed to the buffer
> > descriptors, are allocated only as needed; which makes the overhead
> > of a large local_buffers setting prett
Ð ÐÐÑ, 19/03/2005 Ð 12:57 -0500, Tom Lane ÐÐÑÐÑ:
> It's already true that the individual buffers, as opposed to the buffer
> descriptors, are allocated only as needed; which makes the overhead
> of a large local_buffers setting pretty small if you don't actually do
> much with temp tables in a giv
Tom Lane wrote:
I'd go with PlannerState. QueryState for some reason sounds more like
execution-time state.
Well, not to me :) It just makes sense to me that QueryState as the
working state associated with a Query. Not sure it makes a big
difference, though.
Pulling the "planner internal" stuff
Hi all,
When pgfoundry was opened, there was some talk about moving the projects
from gborg there. This has not, to date, happened. Is there any chance
of this happening now, even if only for the specific project? I feel
really bad about releasing a new version of ole db, with the news of the
p
46 matches
Mail list logo
