On Tue, Jan 17, 2006 at 01:28:03PM -0500, Jaime Casanova wrote:
> is the same problem as with temp tables, you must put their creation,
> and in this case even the nextval in an execute...
Curious that it works in 8.0, though. I wonder if the failure in
8.1 is an artifact of changing sequence fun
Neil Conway <[EMAIL PROTECTED]> writes:
> While reviewing Joachim Wieland's patch to add a pg_cursors system view,
> I noticed that the patch assumes that debug_query_string contains the
> portion of the submitted query string that corresponds to the SQL
> statement we are currently executing. That
sorry for noise
cheers
andrew
---(end of broadcast)---
TIP 6: explain analyze is your friend
While reviewing Joachim Wieland's patch to add a pg_cursors system view,
I noticed that the patch assumes that debug_query_string contains the
portion of the submitted query string that corresponds to the SQL
statement we are currently executing. That is incorrect:
debug_query_string contains the *
On Tue, 2006-01-17 at 21:43 +, Simon Riggs wrote:
> OK My interest was in expanding the role of HashAgg, which as Rod
> says can be used to avoid the sort, so the overlap between those ideas
> was low anyway.
Am I right in thinking that HashAgg would almost always be quicker than
SortAgg,
On Tue, 2006-01-17 at 14:41 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Mon, 2006-01-16 at 12:36 -0500, Tom Lane wrote:
> >> The tricky part is to preserve the existing guarantee that tuples are
> >> merged into their aggregate in arrival order.
>
> > You almost had me
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2006-01-16 at 12:36 -0500, Tom Lane wrote:
>> The tricky part is to preserve the existing guarantee that tuples are
>> merged into their aggregate in arrival order.
> You almost had me there... but there isn't any "arrival order".
The fact that it
On Mon, 2006-01-16 at 12:36 -0500, Tom Lane wrote:
> The tricky part is to preserve the existing guarantee that tuples are
> merged into their aggregate in arrival order. (This does not matter for
> the standard aggregates but it definitely does for custom aggregates,
> and there will be unhappy
On 1/17/06, Daniel Schuchardt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> here is a testcase:
>
> CREATE OR REPLACE FUNCTION testseq()
> RETURNS void AS
> $BODY$
> BEGIN
> CREATE TEMP SEQUENCE test;
> PERFORM testseq1();
> DROP SEQUENCE test;
> RETURN;
> END; $BODY$
> LANGUAGE 'plpgsql' VOLATILE;
>
"R, Rajesh (STSD)" <[EMAIL PROTECTED]> writes:
> But the bottomline is the default test does not include in the
> test code.
That's odd. Is getaddrinfo a macro on Tru64? If so, the appropriate
patch would probably make the test look more like the tests for finite()
and friends:
dnl Cannot use
I modified postgresql 8.1 for its optimization part. Basically I reset
the whole memory context
after query optimization (but store the query plan in top level memory
context so it is not lost).
Later at certain time, I match queries to the pre-computed query plans
(to avoid re-compiling the whole
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> The overwhelming amount of development work gets done against HEAD. I would
> start with a once a day run against HEAD, and possibly one against the
> latest stable branch (currently REL8_1_STABLE in cvs). That would get you
> 99% of the possible benef
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2006-01-16 at 20:02 -0500, Tom Lane wrote:
>> But our idea of the number of batches needed can change during that
>> process, resulting in some inner tuples being initially assigned to the
>> wrong temp file. This would also be true for hashagg.
>
> > http://www.postgresql.org/docs/8.1/static/indexes-types.html
> > says:
> > The optimizer can also use a B-tree index for queries involving the
> > pattern matching operators LIKE, ILIKE, ~, and ~*, if the
> pattern is a
> > constant and is anchored to the beginning of the string -
> for exa
Hi,
here is a testcase:
CREATE OR REPLACE FUNCTION testseq()
RETURNS void AS
$BODY$
BEGIN
CREATE TEMP SEQUENCE test;
PERFORM testseq1();
DROP SEQUENCE test;
RETURN;
END; $BODY$
LANGUAGE 'plpgsql' VOLATILE;
ALTER FUNCTION testseq() OWNER TO postgres;
CREATE OR REPLACE FUNCTION testseq1()
RET
I have a table, "path", which is:
pathid | integer | not null default
nextval('path_pathid_seq'::regclass)
path | text| not null
Indexes:
"path_pkey" PRIMARY KEY, btree (pathid)
"path_name_idx" btree (path)
The table contains approx 1.2 million rows, of which all are unique.
(both
Joachim Wieland said:
> Do you want to put it on the postgresql.org site nevertheless? Is it
> too big to be mirrored and should be recreated on every webserver? We
> might need one copy for the last version of every major release as well
> as one for cvs. The latter should get updated regularly of
On Tue, Jan 17, 2006 at 09:34:06AM +0900, Michael Glaesemann wrote:
> Along those lines, I wonder if a CSS couldn't be worked up to
> integrate the look with the rest of the site.
Yes, it's stylesheet based. However I don't know yet to what extend you can
change the look. It allows for a custom he
On Mon, Jan 16, 2006 at 07:42:35PM -0500, Robert Treat wrote:
> This was my plan all along, just been waiting for someone to make it work
> with the postgresql code and then send instructions to the postgresql web
> team on how to set it up.
I volunteer to tell you after I've found out for myself
On Tue, Jan 17, 2006 at 12:15:02AM -0500, Tom Lane wrote:
> The thing seems to have only the very vaguest grasp on whether it is
> parsing C or C++ ... or should I say that it is convinced it is parsing
> C++ despite all evidence to the contrary? I'd be happier with the
> pretty pictures if they h
20 matches
Mail list logo
