Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > FWIW this is a hard problem; Oracle is the only database I know of
> > that's tackled it.
>
> It seems fair to point out that this is the tradeoff you must buy into
> when using PREPARE. You can have a query plan that is tailored to
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> FWIW this is a hard problem; Oracle is the only database I know of
> that's tackled it.
It seems fair to point out that this is the tradeoff you must buy into
when using PREPARE. You can have a query plan that is tailored to the
specific parameter valu
FWIW this is a hard problem; Oracle is the only database I know of
that's tackled it.
On Wed, Dec 01, 2004 at 11:38:25AM +1100, Neil Conway wrote:
> On Tue, 2004-11-30 at 22:19 +, PostgreSQL Bugs List wrote:
> > This means that using a prepared statement instead of a direct query is
> > *40*
On Tue, 2004-11-30 at 22:19 +, PostgreSQL Bugs List wrote:
> This means that using a prepared statement instead of a direct query is *40*
> times slower!
Yes, it's a known (documented) issue that you can get inferior query
plans using prepared statements. I don't know of an easy way to fix
th
The following bug has been logged online:
Bug reference: 1334
Logged by: A. Steinmetz
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.6
Operating system: Linux
Description:PREPARE creates bad execution plan (40x slower)
Details:
Direct excution of:
ex
I wrote:
> It looks like we changed the code to match what Oracle does on
> 7/27/2003, but forgot to fix the documentation. Will fix, thanks
> for the report.
Actually, someone already fixed the documentation in CVS tip: see
http://developer.postgresql.org/docs/postgres/functions-string.html
"Darrell Walisser" <[EMAIL PROTECTED]> writes:
> It appears that "'" is being considered as a whitespace (and perhaps other
> punctuation, haven't checked myself):
Hmm. The documentation is at variance with the code, which clearly says
* Returns string, with first letter of each word in
It appears that "'" is being considered as a whitespace (and perhaps other
punctuation, haven't checked myself):
initcap(text) " Convert first letter of each word (whitespace-separated) to
upper case "
Sample SQL: select initcap('grahm''s little angel');
Incorrect Result (Note capital S): 'Grah
Is there some problem with using ecpg on Win32? I was not aware of one.
---
PostgreSQL Bugs List wrote:
>
> The following bug has been logged online:
>
> Bug reference: 1319
> Logged by: Tom O'Connell
>
> E
Folks,
Here's the relevant discussion with Tom Lane's response.
http://archives.postgresql.org/pgsql-bugs/2004-09/msg00226.php
This bug is causing the load on our heavily used postgres server to go
into the 12-15 range. Any idea whether this bug has been resolved?
Thanks
--
Shahbaz Javeed
-
Robert Osowiecki <[EMAIL PROTECTED]> writes:
> While doing some large update on table with over 1 million records:
> HashBatchContext: 360701952 total in 52 blocks; 7158680 free (140
> chunks); 353543272 used
Evidently this hashtable got out of hand :-(
> Query is EXPLAIN-ed as follows:
> Hash
I am using postgres
8.0.0 beta5. The problem I am having is when I start windows, the postgres
service doesn't start automatically. The weird thing is that it used to start
automatically. There doesn't seem to be any way to start the service
as an underprivileged user if I am an administr
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> At this point, the vacuum is *still* in progress (after 8 hours) and disc
> activity is exclusively the result of this vacuum, about 140 blocks/second
> with no disc queues. Is this likely to be a bug or just a scalability issue
> involving va
> Test platform = Win 2000 plus all service packs, hotfixes.
> No previous PostgreSQL ever installed on the machine before.
>
> 8.0.0 beta 5 installation executable from
> http://pgfoundry.org/projects/pginstaller
>
> Installed NOT AS A SERVICE, repeat NOT as a WinNT/2K service.
> Told installer
While doing some large update on table with over 1 million records:
update tordspecif set
sp_vat=vv_vat,
sp_vat_opis=vv_vat_opis,
sp_ar_sww=vv_sww
from varticlevat
where sp_az_artsize=vv_artsize
PostgreSQL 8.0.0beta5 on i686-pc-linux-gnu, compiled by GCC 2.96
reported
Test platform = Win 2000 plus all service packs, hotfixes.
No previous PostgreSQL ever installed on the machine before.
8.0.0 beta 5 installation executable from
http://pgfoundry.org/projects/pginstaller
Installed NOT AS A SERVICE, repeat NOT as a WinNT/2K service.
Told installer to put installat
The following bug has been logged online:
Bug reference: 1333
Logged by: Keith Halewood
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.5
Operating system: HP-UX 11i
Description:vacuum full apparently fails to complete
Details:
We have a database of ap
17 matches
Mail list logo
