Re: [GENERAL] A query planner that learns

2006-10-16 Thread Jochem van Dieten
Scott Marlowe wrote: While all the talk of a hinting system over in hackers and perform is good, and I have a few queries that could live with a simple hint system pop up now and again, I keep thinking that a query planner that learns from its mistakes over time is far more desirable. Is it

Re: [GENERAL] [JDBC] Is what I want possible and if so how?

2006-07-05 Thread Jochem van Dieten
Csaba Nagy wrote: On Mon, 2006-07-03 at 17:03, Tom Lane wrote: status and TX2's select will not return the row. This isn't entirely perfect because LIMIT acts before FOR UPDATE: TX2's select will return nothing, rather than selecting the next available row as you might wish. So you might want

[GENERAL] Open Source database comparison

2005-06-10 Thread Jochem van Dieten
FYI: http://www.fabalabs.org/research/papers/FabalabsResearchPaper-OSDBMS-Eval.pdf Jochem ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [GENERAL] pg_dump 8.0.3 failing against PostgreSQL 7.3.2

2005-06-07 Thread Jochem van Dieten
Tom Lane wrote: Well, that trace makes it look like it's unhappy about the null::text in the command, because there is no other typecast in the SELECT target statement. Looking at the 7.3 code, the only very plausible reason for the failure is if either unknown or text has disappeared from

Re: [GENERAL] pg_dump 8.0.3 failing against PostgreSQL 7.3.2

2005-06-07 Thread Jochem van Dieten
Tom Lane wrote: I wrote: [ light dawns ] You've created a table named text, haven't you? Yes, there is such a table. But even if I put the schema with that table in the search_path I can't reproduce the error from psql. You need this patch. I prefer the interpretation My customer

[GENERAL] pg_dump 8.0.3 failing against PostgreSQL 7.3.2

2005-06-06 Thread Jochem van Dieten
I am experiencing a problem with dumping one specific database on a cluster. All 143 other databases dump without giving errors. The server runs PostgreSQL 7.3.2 on OpenBSD (I know :). pg_dump is version 8.0.3 on Windows (upgraded from 8.0.1 which had the same problem). The error message is:

Re: [GENERAL] pg_dump 8.0.3 failing against PostgreSQL 7.3.2

2005-06-06 Thread Jochem van Dieten
Tom Lane wrote: Jochem van Dieten [EMAIL PROTECTED] writes: Below I have copy pasted the console log which has some additional information. This bug, or a related one, seems to have been registered previously as bug #1455 http://archives.postgresql.org/pgsql-bugs/2005-02/msg00021.php Yeah

Re: [GENERAL] pg_dump 8.0.3 failing against PostgreSQL 7.3.2

2005-06-06 Thread Jochem van Dieten
Tom Lane wrote: Jochem van Dieten [EMAIL PROTECTED] writes: (gdb) break elog Breakpoint 1 at 0x16d8f8 (gdb) bt #0 0x403ca553 in ?? () from /usr/lib/libc.so.28.5 #1 0x10e604 in mdread () #2 0x10f31f in smgrread () You forgot to continue until the breakpoint is reached --- this trace just

Re: [GENERAL] pg_dump 8.0.3 failing against PostgreSQL 7.3.2

2005-06-06 Thread Jochem van Dieten
Tom Lane wrote: [ studies 7.3 code a bit ] It might work better to set the breakpoint at elog_message_prefix, assuming you've got logging dialed down to the point where only actual ERRORs go to the log. Attaching to process 10284 0x403827df in ?? () (gdb) symbol-file postmaster Reading

Re: [GENERAL] PostgreSQL vs. InnoDB performance

2005-06-03 Thread Jochem van Dieten
Peter Eisentraut wrote: On a particular system, loading 1 million rows (100 bytes, nothing fancy) into PostgreSQL one transaction at a time takes about 90 minutes. Doing the same in MySQL/InnoDB takes about 3 minutes. InnoDB is supposed to have a similar level of functionality as far as the

Re: [GENERAL] functions/operators with 2 sets as arguments

2003-12-07 Thread Jochem van Dieten
Tom Lane wrote: Jochem van Dieten [EMAIL PROTECTED] writes: While trying to create an operator to test if 2 intervals overlap, I ran into the following limitation: ERROR: Functions and operators can take only one set argument (PostgreSQL 7.3.2 on OpenBSD) It's still there, and is unlikely

Re: [GENERAL] To Postgres Devs : Wouldn't changing the select limit

2001-10-18 Thread Jochem van Dieten
Bruce Momjian wrote: Bruce Momjian writes: Break the SQL code that has been implemented for prior versions?? Bummer ;((. Yes, but we don't follow the MySQL behavior, which we copied when we added LIMIT. Seems we should agree with their implementation. Isn't it much worse to not follow

Re: [GENERAL] ODBC error

2001-08-20 Thread Jochem van Dieten
Michelle Murrain wrote: I'm trying to isolate a problem - using Cold Fusion, and sending to pg a large text block, I'm getting an error: ODBC Error Code = 08S01 (Communication link failure) Error while executing the query; Query string is too long Is this a Cold Fusion problem, or a

[GENERAL] PostgresQL equivalent of NOCOUNT

2001-08-14 Thread Jochem van Dieten
Does PostgresQL have some way to make update, insert and delete queries not return the number of affected rows? I know that in MS SQL one would use NOCOUNT for that. TIA, Jochem ---(end of broadcast)--- TIP 3: if posting/reading through

Re: [GENERAL] PostgresQL equivalent of NOCOUNT

2001-08-14 Thread Jochem van Dieten
Tom Lane wrote: Jochem van Dieten [EMAIL PROTECTED] writes: Does PostgresQL have some way to make update, insert and delete queries not return the number of affected rows? I know that in MS SQL one would use NOCOUNT for that. Uh ... why? Seems like a useless anti-feature. Certainly