On Mon, 03 Jul 2006, Tom Lane wrote:
- Seq Scan on organization (cost=0.00..480.95 rows=1 width=4) (actual
time=0.071..69.702 rows=1892 loops=1)
Filter: ((organization_location)::text ~* 'warszawa'::text)
How many rows are there in the organization table?
About 9000. And about
If a column type is being changed with USING (NULL) clause,
NOT NULL constraint seems not to be checked:
[EMAIL PROTECTED] CREATE table test (x integer not null);
CREATE TABLE
[EMAIL PROTECTED] INSERT INTO test VALUES (1);
INSERT 0 1
[EMAIL PROTECTED] ALTER TABLE test ALTER x TYPE boolean USING
Tomasz Ostrowski [EMAIL PROTECTED] writes:
I think because there is no good solution to this - no statistical
information is going to predict how much data will match a regular
expression.
Well, it's certainly hard to imagine simple stats that would let the
code guess that, say, warsa and
Alexander M. Pravking [EMAIL PROTECTED] writes:
If a column type is being changed with USING (NULL) clause,
NOT NULL constraint seems not to be checked:
Hm, the code seems to have provisions to check SET NOT NULL, but
it fails to check pre-existing NOT NULL attributes :-(
On Tue, 04 Jul 2006, Tom Lane wrote:
I think the real problem here is that regex matching is the wrong
tool for the job. Have you looked into a full-text index
(tsearch2)?
So much to do with so little time...
I've briefly looked into it but:
- it's complicated;
- it is not needed - basic
On Tue, Jul 04, 2006 at 04:44:08PM +0200, Tomasz Ostrowski wrote:
On Tue, 04 Jul 2006, Tom Lane wrote:
I think the real problem here is that regex matching is the wrong
tool for the job. Have you looked into a full-text index
(tsearch2)?
So much to do with so little time...
For what
Tomasz Ostrowski [EMAIL PROTECTED] writes:
So why estimate regex expressions if there is no estimation possible?
Let's set this estimate to be pessimistic (match everything or
everything not null) and it will choose better plans.
Better plans for this specific example, worse plans for other
The following bug has been logged online:
Bug reference: 2513
Logged by: tommaso gastaldi
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: Windows XP
Description:What? OleDbSchemaGuids not supported ?!!! This is
CRUCIAL!
Details:
I cannot
The following bug has been logged online:
Bug reference: 2512
Logged by: Phil Frost
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: Mac OS 10.4.7
Description:pg_dump produces unrestorable output when table and
serial sequence are not in
Phil Frost [EMAIL PROTECTED] writes:
Creating the database:
test= create schema private;
test= create table o(i serial primary key);
test= alter sequence o_i_seq set schema private;
I would argue that the bug is we allow you to do the above ;-).
It's not really sane to move a serial sequence
10 matches
Mail list logo
