"Anibal David Acosta" writes:
> Because I need to get all rows where datetime is greater than (for example)
> '2012-10-10 00:00:00' but ignoring timezone, so basically I need to truncate
> timezone
> This can be done by converting to timestamp without timezone.
[ shrug... ] It can also be done w
I wrote:
> Sergio Gabriel Rodriguez writes:
>> I never use oprofile, but for a few hours into the process, I could take
>> this report:
>> 1202449 56.5535 sortDumpableObjects
> Hm. I suspect a lot of that has to do with the large objects; and it's
> really overkill to treat them as full-fledge
Because I need to get all rows where datetime is greater than (for example)
'2012-10-10 00:00:00' but ignoring timezone, so basically I need to truncate
timezone
This can be done by converting to timestamp without timezone.
-Mensaje original-
De: Tom Lane [mailto:t...@sss.pgh.pa.us]
Env
Sergio Gabriel Rodriguez writes:
> On Thu, Oct 11, 2012 at 7:16 PM, Tom Lane wrote:
>> It's pretty hard to say without knowing a lot more info about your system
>> than you provided. One thing that would shed some light is if you spent
>> some time finding out where the time is going --- is the
On Thu, Oct 11, 2012 at 7:16 PM, Tom Lane wrote:
>
> It's pretty hard to say without knowing a lot more info about your system
> than you provided. One thing that would shed some light is if you spent
> some time finding out where the time is going --- is the system
> constantly I/O busy, or is
On 11.10.2012 17:15, Korisk wrote:
> "IOS scan" ?
> Index Only Scan
>
> What's your seq_page_cost and random_page_cost?
>
> hashes=# SELECT name, setting, reset_val FROM pg_settings WHERE setting <>
> reset_val;
> name |setting | reset_val
> -
On 12.10.2012 09:10, Sergey Konoplev wrote:
> What I can not understand is why the seq scan's estimated cost is
> better the index scan's one. It depends on the number of pages in
> index/relation. May be the index is heavily bloated?
The IOS cost depends on other things too. The index can't be re
"Anibal David Acosta" writes:
> I have a table with a column of type timestamp with time zone, this column
> has an index
> If I do a select like this
> select * from mytable where cast(my_date as timestamp without time zone) >
> '2012-10-12 20:00:00'
> this query will use the index over the my_d
On Fri, Oct 12, 2012 at 2:05 PM, Anibal David Acosta wrote:
> I have a table with a column of type timestamp with time zone, this column
> has an index
>
> If I do a select like this
>
> select * from mytable where cast(my_date as timestamp without time zone) >
> '2012-10-12 20:00:00'
>
> this que
I have a table with a column of type timestamp with time zone, this column
has an index
If I do a select like this
select * from mytable where cast(my_date as timestamp without time zone) >
'2012-10-12 20:00:00'
this query will use the index over the my_date column?
Thanks
> What I can not understand is why the seq scan's estimated cost is
> better the index scan's one. It depends on the number of pages in
> index/relation. May be the index is heavily bloated?
Mm i don't know how to see bloating level. But the index was created by
create index on hashcheck using btr
On Thu, Oct 11, 2012 at 9:14 PM, Korisk wrote:
> Strange situation.
> After indexscan enabling the cost is seriously decreased.
AFAIK when the planner has to choose between index scans and seq scans
and both of this options are off it uses one of this strategies anyway
but puts 100.00 as
12 matches
Mail list logo
