Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > However I have the complementary reaction. I find peeking at the first
> > bind parameter to be scary as hell. Functions seem slightly less scary.
>
> FWIW, we only do it in the context of unnamed parameterized que
Greg Stark <[EMAIL PROTECTED]> writes:
> However I have the complementary reaction. I find peeking at the first
> bind parameter to be scary as hell. Functions seem slightly less scary.
FWIW, we only do it in the context of unnamed parameterized queries.
As the protocol docs say, those are optimiz
Martin Sarsale <[EMAIL PROTECTED]> writes:
> I indexed columns c and d (separately) but this query used the slow
> seqscan instead of the index scan:
> select * from t where c<>0 or d<>0;
> After playing some time, I noticed that if I change the "or" for an
> "and", pg used the fast index scan (b
Another option here is to use a partial index. You can index on some other
column -- perhaps the column you want the results ordered by where the where
clause is true.
Something like:
create index t_idx on t (name) where c>0 and d>0;
then any select with a matching where clause can use the inde
[I'm actually responding to the previous post from Tom Lane, but I've deleted
it and the archives seem to be down again.]
The assumption being made is that the first provided result is representative
of all future results. I don't see any reason that making this assumption of
all stable functio
On Mon, 30 Aug 2004, Martin Sarsale wrote:
> On Mon, 2004-08-30 at 15:06, Merlin Moncure wrote:
> > create function is_somethingable (ctype, dtype) returns boolean as
>
> Thanks, but I would prefer a simpler solution.
>
> I would like to know why this uses a seqscan instead of an index scan:
>
> c
create index t_idx on t((c+d));
select * from t where c+d > 0;
Why not :
select ((select * from t where c<>0::bigint) UNION (select * from t where
d<>0::bigint))
group by whatever;
or someting ?
---(end of broadcast)---
TIP 3: if pos
Another primary key trick :
If you insert records with a serial primary key, and rarely delete them
or update the timestamp, you can use the primary key to compute an
approximate number of rows.
a := SELECT pkey FROM table WHERE timestamp() > threshold ORDER BY
timestamp ASC LIMIT 1;
On Mon, Aug 30, 2004 at 21:21:26 +0200,
Pierre-Frédéric Caillaud <[EMAIL PROTECTED]> wrote:
> >>Also, count(*) is likely to always generate a seq scan due to the way
> >>aggregates are implemented currently in pgsql. you might want to try:
>
>
> By the way, in an ideal world, count(*) sh
On Sun, Aug 29, 2004 at 06:03:43PM -0400, Tom Lane wrote:
> >> select somefield from sometable where timestampfield > now()-'60
> >> seconds'::interval
>
> This is a FAQ, but since the archives don't seem to be up at the moment,
> here's the answer once again:
>
> The expression "now() - somethin
Yeah! Bind variable peeking is great news. I did actually read the guff, but forgot
about that.
Version 8 is looking great on paper, I hope I'll get a chance to play wth it soon.
I can kind of appreciate your point about peeking stable functions, however, I would
have thought
that if it was pos
11 matches
Mail list logo
