Hi,
I'm playing around with 9.2 beta4 and was looking into the new Index Only Scan
feature.
I was a bit surprised that a "count(*)" query does not use an index.
Not even a count(col) where col is the PK of the table.
Is that intended? If so, why is that the case?
I would have thought that this
Hi,
Sorry to bother with the stupid question guys - I'm new to the Postgres.
I'm having issue allowing user to access the database - the user is
not allowed to access the data. I do the following:
1) grant all on database testdb table mytable to trinity;
postgres=# \l
Hey Matvey,
2012/8/26 Matvey Teplov
> Hi,
>
> Sorry to bother with the stupid question guys - I'm new to the Postgres.
> I'm having issue allowing user to access the database - the user is
> not allowed to access the data. I do the following:
> 1) grant all on database testdb table mytable to
On Sun, 2012-08-26 at 13:10 +0200, Matvey Teplov wrote:
> Hi,
>
> Sorry to bother with the stupid question guys - I'm new to the Postgres.
> I'm having issue allowing user to access the database - the user is
> not allowed to access the data. I do the following:
> 1) grant all on database testdb
Michael Clark writes:
> It does in fact appear that we are getting false-positives.
> When trying to start PG using pg_ctl, I am getting this response:
> pg_ctl: another server might be running; trying to start server anyway
> 2012-08-26 04:46:02.211 GMT [] - FATAL: lock file "postmaster.pid" alr
Thomas Kellerer writes:
> I'm playing around with 9.2 beta4 and was looking into the new Index Only
> Scan feature.
> I was a bit surprised that a "count(*)" query does not use an index.
Works for me. However, the cost estimate for that is heavily dependent
on how much of the table is known all
Thank guys! Got it.
On Sun, Aug 26, 2012 at 1:37 PM, Guillaume Lelarge
wrote:
> On Sun, 2012-08-26 at 13:10 +0200, Matvey Teplov wrote:
>> Hi,
>>
>> Sorry to bother with the stupid question guys - I'm new to the Postgres.
>> I'm having issue allowing user to access the database - the user is
>> n
Tom Lane wrote on 26.08.2012 16:31:
Thomas Kellerer writes:
I'm playing around with 9.2 beta4 and was looking into the new Index Only Scan
feature.
I was a bit surprised that a "count(*)" query does not use an index.
Works for me. However, the cost estimate for that is heavily dependent
on
It's become clear I need to go back and rethink my logic for this
functionality. Thanks for all of the suggestions.
-- John
On Sat, Aug 25, 2012 at 12:40 AM, Chris Angelico wrote:
> On Sat, Aug 25, 2012 at 8:25 AM, John D. West wrote:
> > I *think* my independent processes are cleaning u
On Sun, Aug 26, 2012 at 10:25 AM, Tom Lane wrote:
> Michael Clark writes:
> > PID 8574 is actually iTunes, not PG,
>
> iTunes? What is that doing running under PG's userid?
>
>
>
We back our client application with PG, each OSX user gets their own
instance of PG.
It runs as that OSX user.
>
On 26 Aug 2012, at 17:21, Michael Clark wrote:
> On Sun, Aug 26, 2012 at 10:25 AM, Tom Lane wrote:
>> Michael Clark writes:
>> > PID 8574 is actually iTunes, not PG,
>>
>> iTunes? What is that doing running under PG's userid?
>>
>
>
> We back our client application with PG,
> each OSX user
On Sun, Aug 26, 2012 at 1:25 PM, Alban Hertroys wrote:
> > We back our client application with PG,
>
> > each OSX user gets their own instance of PG.
>
> Are you certain that's necessary?
>
>
It was a decision made, weighing various trade-offs, 4 years ago now.
> > In the wild this scenario has
> 1) First, in LedgerSMB,
What a pity that this is implemented in a write-only programming
language and as a "web application" instead of an actual GUI...
> we started using it to create consistent interfaces to sets of
> storage tables. The storage tables would behave differently, but
> w
I have a stored procedure that renames a table as part of a partitioning
scheme, then re-creates it.
Up until recently (I'm not sure what changed), renaming the table would
cause the pkey index/constraint, as well as all other indexes, to be
renamed according to the new table name.
However, they no
On Sun, Aug 26, 2012 at 8:02 AM, Thomas Kellerer wrote:
> Tom Lane wrote on 26.08.2012 16:31:
>
>> Thomas Kellerer writes:
>>>
>>> I'm playing around with 9.2 beta4 and was looking into the new Index Only
>>> Scan feature.
>>> I was a bit surprised that a "count(*)" query does not use an index.
>
Jeff Janes writes:
> On Sun, Aug 26, 2012 at 8:02 AM, Thomas Kellerer wrote:
>> Should the following setup qualify for an index scan?
> ... Also, your filler is highly compressible, which means the table is
> much smaller than you might think.
Yeah. I see something like 100 rows per page with
2012/8/26 Tom Lane :
> Jeff Janes writes:
>> On Sun, Aug 26, 2012 at 8:02 AM, Thomas Kellerer wrote:
>>> Should the following setup qualify for an index scan?
>
>> ... Also, your filler is highly compressible, which means the table is
>> much smaller than you might think.
>
> Yeah. I see somethi
Moshe Jacobson writes:
> I have a stored procedure that renames a table as part of a partitioning
> scheme, then re-creates it.
> Up until recently (I'm not sure what changed), renaming the table would
> cause the pkey index/constraint, as well as all other indexes, to be
> renamed according to th
Pavel Stehule writes:
> is possible use seqscan for index?
No, not for a normal indexscan --- concurrent page splits would break
it.
VACUUM can do that, mainly because it doesn't care if it visits some
entries twice (and even then, it has to add a lot of pushups to ensure
it doesn't miss any ent
Jeff Janes wrote on 26.08.2012 20:45:
The seq scan is estimated to use sequential reads, while the
index-only scan is estimated to use random reads (because the index is
scanned in logical order, not physical order).
If you set random_page_cost equal to seq_page_cost, that would
artificially fav
On Sun, Aug 26, 2012 at 12:58 PM, Thomas Kellerer wrote:
> Jeff Janes wrote on 26.08.2012 20:45:
>
>> The seq scan is estimated to use sequential reads, while the
>> index-only scan is estimated to use random reads (because the index is
>> scanned in logical order, not physical order).
>>
>> If yo
Jeff Janes wrote on 26.08.2012 22:26:
The seq scan is estimated to use sequential reads, while the
index-only scan is estimated to use random reads (because the index is
scanned in logical order, not physical order).
Sounds like scanning the index in physical order would be an enhancement.
That
On Aug 27, 2012 12:58 AM, "Wolfgang Keller" wrote:
>
> > 1) First, in LedgerSMB,
>
>
>
> What a pity that this is implemented in a write-only programming
> language and as a "web application" instead of an actual GUI...
>
>
Actually this has continued to remind me how ugly HTTP is for actual
a
Hello ,
Could you please tell me some one ,how to do connection PGBouncer using Perl
DBI module ?
Thanks
Prashant
On 08/27/2012 09:51 AM, Prashant Bharucha wrote:
Hello ,
Could you please tell me some one ,how to do connection PGBouncer using
Perl DBI module ?
Exactly the same way you connect to PostgreSQL normally: specify a
hostname, port and database name. Instead of specifying those for the
PostgreSQ
OK. I won't go into details about why I need them, since no one wants
a long story.
Simply put, I'm looking for odbc drivers for postgresql that will work with NT4.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
And many others errors when xsome user connect to database x, schema
xxx. PG 8.4.
Problems started about same time as search_path has SET.
search_path has reset, but did'nt help.
ALTER DATABASE x SET search_path=some, public;
-- xxx wasn't in that list
ALTER DATABASE x RESET search_path; - has
2012/8/26 Tom Lane :
> Pavel Stehule writes:
>> is possible use seqscan for index?
>
> No, not for a normal indexscan --- concurrent page splits would break
> it.
>
and what about seq scan for prefetch index - and processing should be
random, but over pages in cache?
Pavel
> VACUUM can do that,
28 matches
Mail list logo
