On Tue, 2006-05-09 at 13:29 +0200, PFC wrote:
> 0.101 ms BEGIN
> 1.451 ms CREATE TEMPORARY TABLE tmp ( a INTEGER NOT NULL, b INTEGER NOT
> NULL, c TIMESTAMP NOT NULL, d INTEGER NOT NULL ) ON COMMIT DROP
> 0.450 ms INSERT INTO tmp SELECT * FROM bookmarks ORDER BY annonce_id DESC
> LIMIT 20
> 0.4
On Wed, 2005-12-14 at 17:47 -0500, Tom Lane wrote:
> That plan looks perfectly fine to me. You could try forcing some other
> choices by fooling with the planner enable switches (eg set
> enable_seqscan = off) but I doubt you'll find much improvement. There
> are too many rows being pulled from o
On Sat, 2005-12-03 at 23:00 +, Rodrigo Madera wrote:
> CREATE TABLE person(
>id bigint PRIMARY KEY,
>first_name TEXT,
>age INT,
>mother bigint REFERENCES person,
>father biging REFERENCES person,
>siblings array of bigints (don't remember the syntax, but you get the
>
On Fri, 2005-11-11 at 10:53 -0500, Tom Lane wrote:
> After re-reading your explanation of what you're doing with the data,
> I thought of a possible explanation. Is the "source" value exactly
> correlated with the external_id_map primary key?
Sort of. In this case, at the beginning of external_i