From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andreas Joseph Krogh <andreas(at)visena(dot)com> |
Cc: | Evgeniy Shishkin <itparanoia(at)gmail(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Searching GIN-index (FTS) and sort by timestamp-column |
Date: | 2016-03-17 17:57:46 |
Message-ID: | 4024.1458237466@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Andreas Joseph Krogh <andreas(at)visena(dot)com> writes:
> P torsdag 17. mars 2016 kl. 18:20:23, skrev Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> FWIW, the reason for that is that the int8_ops operator class that
> btree_gin creates doesn't contain any cross-type operators. Probably
> wouldn't be that hard to fix if somebody wanted to put in the work.
> Can you explain why it works when using prepared statement without casting?
If you mean the example
prepare fish AS SELECT del.id , del.received_timestamp FROM delivery del
WHERE 1= 1 AND del.fts_all @@ to_tsquery('simple', $1) AND
del.folder_id = $2 ORDER BY del.received_timestamp DESC LIMIT 101 OFFSET 0;
you didn't provide any type for the parameter $2, so the parser had to
infer a type, and the applicable heuristic here is "same type that's on
the other side of the operator". So you ended up with "bigint = bigint"
which is in the btree_gin operator class. If you'd specified the
parameter's type as integer, it would've worked the same as Evgeniy's
example.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Stibrany | 2016-03-17 20:45:10 | Disk Benchmarking Question |
Previous Message | Andreas Joseph Krogh | 2016-03-17 17:30:12 | Re: Searching GIN-index (FTS) and sort by timestamp-column |