Zeljko Vrba [EMAIL PROTECTED] writes:
Is there yet another way of making WHERE field = ANY (subselect
returning an array) work? Or make postgres to use index?
You could use the int_array_enum() function from the contrib/int_agg module.
Also, what is the limit on the number of elements in
Tom Lane [EMAIL PROTECTED] writes:
The EXPLAIN ANALYZE overhead for the Append is still pretty heavy,
but when comparing actual runtimes for the two queries, they are
now very nearly the same.
How hard would it be to have Postgres actually remove the gettimeofday
overhead from the EXPLAIN
I think this is the driver's problem. It appears that we are following
the spec, so lets leave this alone.
Regarding what an OUT parameter might mean. We already have some
facility in the FE/BE to indicate the types of the returning columns.
Directionality is implied by where in the bind
Greg Stark [EMAIL PROTECTED] writes:
How hard would it be to have Postgres actually remove the gettimeofday
overhead from the EXPLAIN ANALYZE output?
Personally, I dislike measurement tools that lie to you under the flag
of producing more-easily-interpreted results.
As an example of why this
We've seen two recent reports:
http://archives.postgresql.org/pgsql-admin/2005-04/msg8.php
http://archives.postgresql.org/pgsql-general/2005-05/msg01143.php
of postmaster restart failing because the WAL contains a reference
to a page that no longer exists.
I can think of a couple of possible
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
How hard would it be to have Postgres actually remove the gettimeofday
overhead from the EXPLAIN ANALYZE output?
Personally, I dislike measurement tools that lie to you under the flag
of producing
Tom Lane wrote:
Plan B is for WAL replay to always be willing to extend the file to
whatever record number is mentioned in the log, even though this
may require inventing the contents of empty pages; we trust that their
contents won't matter because they'll be truncated again later in the
It appears that SQL
submited via the latest JDBC driver won't get logged even if
log_min_duration_statement is set appropriately. From what I've found in the
archives, this is becausethe driveruses an "extended" version of the
protocol.
Could somebody point
me at the area of the source
Hello,
I've been using Postgresql-8.0.1 (Release date: 2005-01-31) for my
research work and I guess I finally need some help with it...
I'm not trying to modify the existing functionality, but I want to add
few things. In particular, I'm calculating two new Cost values and I
need to use them
On Wed, 25 May 2005 11:02:11 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Plan B is for WAL replay to always be willing to extend the file to
whatever record number is mentioned in the log, even though this
may require inventing the contents of empty pages; we trust that their
contents won't matter
On Wed, 18 May 2005 13:50:22 +0200, I wrote:
The most important figure is, that at MaxSpeed (/O2) 2x32 is almost
twice as fast as CRC32 while only being marginally slower than CRC32.
^
Silly typo! That should have been:
The most important figure is, that at MaxSpeed (/O2)
Vikram Kalsi [EMAIL PROTECTED] writes:
1.) New Variables ADDED to src/include/nodes/plannodes.h
2.) New Variables ADDED to src/include/nodes/relation.h
...
However, after these modifications the server process crashes on
running a Join query like
select s_suppkey,c_custkey from
Manfred Koizar [EMAIL PROTECTED] writes:
Another idea: WAL replay does not apply changes to nonexistent blocks,
but it keeps a list (hash table, file, whatever) of those blocks.
When a truncate WAL record is found, all entries for blocks affected
by the truncation are removed from the list.
I have added a function in sources and added appropiate lines in pg_proc.h
DATA(insert OID = 2560 ( get_view_column_defaultPGNSP PGUID 12 f f
t f i 1 2283 25 25 21 _null_ _null_ _null_ get_view_column_default -
_null_));
DESCR(get default value for view column);
then make; make install; and
Jaime Casanova [EMAIL PROTECTED] writes:
I have added a function in sources and added appropiate lines in pg_proc.h
DATA(insert OID = 2560 ( get_view_column_defaultPGNSP PGUID 12 f f
t f i 1 2283 25 25 21 _null_ _null_ _null_ get_view_column_default -
_null_));
DESCR(get default value for
Thanks Tom, that solved it...I added the new variables one at a time
and did do a make clean on the first occasion but I must have
forgotten to do it the second time...
I have another question-
The new variables that I've added to Plan and Path i.e.
hutz_tbl_benefit and hutz_idx_benefit are being
On 5/25/05, Tom Lane [EMAIL PROTECTED] wrote:
Jaime Casanova [EMAIL PROTECTED] writes:
I have added a function in sources and added appropiate lines in
pg_proc.h
DATA(insert OID = 2560 ( get_view_column_defaultPGNSP PGUID 12 f f
t f i 1 2283 25 25 21 _null_ _null_ _null_
Andrew - Supernews wrote:
On 2005-05-01, Peter Eisentraut [EMAIL PROTECTED] wrote:
The problem, as I understand it, is that if you have a long-running
query and the client process disappears, the query keeps running and
holds whatever resources it may have until it finishes. In fact, it
Vikram Kalsi [EMAIL PROTECTED] writes:
So, I suppose that during the query planning and optimization stage,
the value of the original variables in the plan are somehow copied to
the plan which is finally returned inside pg_plan_query().
Look in createplan.c --- there are a couple places in
Plan B is for WAL replay to always be willing to extend the file to
whatever record number is mentioned in the log, even though this
may require inventing the contents of empty pages; we trust that their
contents won't matter because they'll be truncated again later in the
replay sequence. This
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Plan B is for WAL replay to always be willing to extend the file to
whatever record number is mentioned in the log, even though this
may require inventing the contents of empty pages; we trust that their
contents won't matter because they'll be
Bruce Momjian pgman@candle.pha.pa.us writes:
Andrew - Supernews wrote:
What's _not_ a good idea is ignoring the EPIPE error from write(), which
seems to currently be reported via ereport(COMMERROR) which doesn't try
and abort the query as far as I can tell.
Where are you seeing this? I
Folks,
Josh Narins asked me to post this as he was unable to post it himself.
http://narins.net:4321/blog/subcountry.html
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
---(end of
23 matches
Mail list logo
