At 11:49 04/11/2005 -0500, Alex Turner wrote:
> I think he meant
>
> create sequence test_seq;
> select setval('test_seq',(select max(primary_key_id) from my_table));
>
> not max value of a serial type.
What I understand, and from what I know by using mysql, is that mysql
auto-adjust the max value
On Wed, 02 Nov 2005 19:29:10 -0800, you wrote:
>It's a migration thing - MySQL prevented this
>situation due to the way it handles auto_increment (it will never assign
>you an id that already exists).
AFAIK, in mysql, if you modify a serial by setting it to the max value for
this type, mysql wi
At 16:23 18/11/2004 +0100, Martijn van Oosterhout wrote:
> The system seems to think that a scan is cheap because the table is so
> small.
The table currently contains just over 1 elements. So 238 rows is a
small part of it.
> Have you ever ANALYZEd that table?
Yes. That and reindex (in case o
At 08:16 19/11/2004 -0600, Bruno Wolff III wrote:
>> The table currently contains just over 1 elements. So 238 rows is a
>> small part of it.
> No, small is typically less than 1%. This depends on the size of the rows
> and how much better accessing disk blocks sequentially is in your
> envirom
At 16:23 18/11/2004 +0100, Martijn van Oosterhout wrote:
> The system seems to think that a scan is cheap because the table is so
> small.
The table currently contains just over 1 elements. So 238 rows is a
small part of it.
> Have you ever ANALYZEd that table?
Yes. That and reindex (in case o
I'm using PG 7.3.4
I've a table with a column of type int8 where I store date-based values,
and an index exists for it.
The problem is that the index is almost never used with the '>' test.
# explain SELECT date FROM album WHERE (date='1093989600');
Index Scan using date_album_key on album (cos
