Given a freshly created table (not vacuumed), and a query that uses an
index-only scan, for example:
CREATE TABLE foo(a int PRIMARY KEY);
INSERT INTO foo SELECT * FROM generate_series(1,100);
ANALYSE foo;
EXPLAIN ANALYSE SELECT count(*) FROM foo WHERE a <= 1;
- Цитат от Oleg Bartunov (o...@sai.msu.su), на 28.01.2012 в 21:04 -
> I suggest you work on more general approach, see
> http://www.sai.msu.su/~megera/wiki/2009-08-12 for example.
>
> btw, I don't like you changed ts_rank_cd arguments.
Hello Oleg,
Thanks for the feedback.
Is it O
Heikki Linnakangas writes:
> Barring objections, I'll write a patch to relax the checking on
> default_text_search_config and temp_tablespaces to match search_path.
This seems like something that's going to come back again and again.
What do you think of changing things so that ALTER ROLE/DATABA
On Fri, Jan 27, 2012 at 5:35 AM, Heikki Linnakangas
wrote:
> On 26.01.2012 04:10, Robert Haas wrote:
>
>>
>> I think you should break this off into a new function,
>> LWLockWaitUntilFree(), rather than treating it as a new LWLockMode.
>> Also, instead of adding lwWaitOnly, I would suggest that we
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> When you try to use the NEW variable in a statement-level trigger, you get
> ERROR: record "new" is not assigned yet
> DETAIL: The tuple structure of a not-yet-assigned record is indeterminate.
> I'm not that familiar with PL/pgSQL code, so I'm not sur
Noah Misch writes:
> On Thu, Jan 26, 2012 at 08:23:34AM -0500, Robert Haas wrote:
>> I'm just going to remove the test. This is not very future-proof and
> [ objections ]
FWIW, I concur with Robert's choice here. This test method is ugly and
fragile, and I'm not even thinking about the questio
When you try to use the NEW variable in a statement-level trigger, you get
ERROR: record "new" is not assigned yet
DETAIL: The tuple structure of a not-yet-assigned record is indeterminate.
which is not too friendly, given that people sometimes forget to specify
FOR EACH at all, get the defaul
Excerpts from Tom Lane's message of sáb ene 28 18:08:36 -0300 2012:
> I thought it'd be a good idea to put in some basic test cases for the
> EvalPlanQual code using the isolationtester infrastructure. While
> fooling with it, I soon ran into this restriction:
>
> if (p->nsteps != nallst
On Thu, Jan 26, 2012 at 08:23:34AM -0500, Robert Haas wrote:
> On Thu, Jan 26, 2012 at 6:55 AM, Noah Misch wrote:
> > On Wed, Jan 25, 2012 at 11:53:10PM -0500, Tom Lane wrote:
> >> Not only is that code spectacularly unreadable, but has nobody noticed
> >> that this commit broke the buildfarm?
> >
On Thu, Jan 12, 2012 at 4:49 AM, Simon Riggs wrote:
> On Thu, Jan 5, 2012 at 6:26 PM, Simon Riggs wrote:
>
>> Patch to remove clog contention caused by dirty clog LRU.
>
> v2, minor changes, updated for recent commits
This no longer applies to file src/backend/postmaster/bgwriter.c, due
to the l
Le 28 janvier 2012 21:46, David E. Wheeler a écrit :
> On Jan 27, 2012, at 2:19 AM, Cédric Villemain wrote:
>
>>> Also --exclude-extension?
>>
>> It might be the default.
>> We need something to dump the content of
>> pg_catalog.pg_extension_script (or whatever table is going to contain
>> SQL cod
I thought it'd be a good idea to put in some basic test cases for the
EvalPlanQual code using the isolationtester infrastructure. While
fooling with it, I soon ran into this restriction:
if (p->nsteps != nallsteps)
{
fprintf(stderr, "invalid
On Jan 27, 2012, at 2:19 AM, Cédric Villemain wrote:
>> Also --exclude-extension?
>
> It might be the default.
> We need something to dump the content of
> pg_catalog.pg_extension_script (or whatever table is going to contain
> SQL code), per extension or all.
I think dim said --no-extensions wo
On 28.01.2012 15:49, Simon Riggs wrote:
On Fri, Jan 27, 2012 at 9:07 PM, Dan Scales wrote:
Also, I missed this before: don't you want to add the checksum calculation
(PageSetVerificationInfo) to mdextend() (or preferably smgrextend()) as well?
Otherwise, you won't be checksumming a bunch o
On Fri, Jan 27, 2012 at 1:45 PM, Jeff Janes wrote:
> On Thu, Jan 12, 2012 at 4:31 AM, Simon Riggs wrote:
>
>> The following patch adds a pgbench option -I to load data using
>> INSERTs, so that we can begin benchmark testing with rows that have
>> large numbers of distinct un-hinted transaction i
2012/1/26 Robert Haas :
> On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai wrote:
>> 2012/1/26 Robert Haas :
>>> I'm wondering if a function would be a better fit than a GUC. I don't
>>> think you can really restrict the ability to revert a GUC change -
>>> i.e. if someone does a SET and then a RESE
create user foouser;
create tablespace temptblspc location '/tmp/tmptblspc';
alter user foouser set temp_tablespaces='temptblspc';
Run pg_dumpall. It will produce a dump like:
...
CREATE ROLE foouser;
ALTER ROLE foouser WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB
LOGIN NOREPLICATION;
ALTE
I suggest you work on more general approach, see
http://www.sai.msu.su/~megera/wiki/2009-08-12 for example.
btw, I don't like you changed ts_rank_cd arguments.
Oleg
On Fri, 27 Jan 2012, karave...@mail.bg wrote:
Hello,
I have developed a variation of cover density ranking functions that count
On 01/28/2012 01:46 PM, Jeff Davis wrote:
On Sat, 2012-01-28 at 13:18 -0500, Tom Lane wrote:
Andrew Dunstan writes:
I'm curious what problem we're actually solving here, though. I've run
the buildfarm countless thousands of times on different VMs, and five of
my seven current animals run in
On Sat, Jan 28, 2012 at 10:18 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I'm curious what problem we're actually solving here, though. I've run
>> the buildfarm countless thousands of times on different VMs, and five of
>> my seven current animals run in VMs, and I don't think I've ever seen
2012/1/26 Robert Haas :
> On Thu, Jan 26, 2012 at 7:27 AM, Kohei KaiGai wrote:
>> It seems to me reasonable design.
>> The attached patch is rebased one according to your perform-deletion patch.
>
> That looks pretty sensible. But I don't think this is true any more:
>
> + Please note that it
On Sat, 2012-01-28 at 13:18 -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > I'm curious what problem we're actually solving here, though. I've run
> > the buildfarm countless thousands of times on different VMs, and five of
> > my seven current animals run in VMs, and I don't think I've ever
On Sat, Jan 28, 2012 at 7:31 AM, Andrew Dunstan wrote:
>
>
> On 01/27/2012 11:52 PM, Noah Misch wrote:
>>>
>>> Is a platform-independent fsync be available at initdb time?
>>
>> Not sure.
>>
>
> It's a macro on Windows that calls _commit(fd), so it should be portable
> enough.
>
> I'm curious what
Andrew Dunstan writes:
> I'm curious what problem we're actually solving here, though. I've run
> the buildfarm countless thousands of times on different VMs, and five of
> my seven current animals run in VMs, and I don't think I've ever seen a
> failure ascribable to inadequately synced files
On Sat, 2012-01-28 at 10:31 -0500, Andrew Dunstan wrote:
> I'm curious what problem we're actually solving here, though. I've run
> the buildfarm countless thousands of times on different VMs, and five of
> my seven current animals run in VMs, and I don't think I've ever seen a
> failure ascriba
On 01/27/2012 11:52 PM, Noah Misch wrote:
Is a platform-independent fsync be available at initdb time?
Not sure.
It's a macro on Windows that calls _commit(fd), so it should be portable
enough.
I'm curious what problem we're actually solving here, though. I've run
the buildfarm countles
On Fri, Jan 13, 2012 at 10:48:56AM +0100, Pierre C wrote:
> Maybe an extra column in pg_proc would do (but then, the proargtypes
> and friends would describe only the sql-callable version) ?
> Or an extra table ? pg_cproc ?
> Or an in-memory hash : hashtable[ fmgr-callable function ] => C version
>
On Thu, Jan 26, 2012 at 5:27 AM, Fujii Masao wrote:
> One thing I would like to ask is that why you think walreceiver is more
> appropriate for writing XLOG_END_OF_RECOVERY record than startup
> process. I was thinking the opposite, because if we do so, we might be
> able to skip the end-of-recov
On Fri, Jan 27, 2012 at 10:05 PM, Jeff Janes wrote:
> On Sat, Jan 21, 2012 at 7:31 AM, Simon Riggs wrote:
>>
>> Yes, it was. Sorry about that. New version attached, retesting while
>> you read this.
>
> In my hands I could never get this patch to do anything. The new
> cache was never used.
>
>
On Fri, Jan 27, 2012 at 9:07 PM, Dan Scales wrote:
> The advantage of putting the checksum calculation in smgrwrite() (or
> mdwrite()) is that it catches a bunch of page writes that don't go through
> the buffer pool (see calls to smgrwrite() in nbtree.c, nbtsort.c, spginsert.c)
I'll have anot
Ok, thanks.
Att,
Fred
2012/1/24 Robert Haas
> On Tue, Jan 24, 2012 at 11:25 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> I doubt it. Almost nothing in the backend is thread-safe. You can't
> >> acquire a heavyweight lock, a lightweight lock, or a spinlock. You
> >> can't do anything th
On 28 January 2012 09:04, Magnus Hagander wrote:
> On Sat, Jan 28, 2012 at 09:57, Magnus Hagander wrote:
>> On Sat, Jan 28, 2012 at 05:30, Tom Lane wrote:
>>> Thom Brown writes:
I'm using latest git master (latest entry
0816fad6eebddb8f1f0e21635e46625815d690b9) and I'm getting an erro
On Sat, Jan 28, 2012 at 09:57, Magnus Hagander wrote:
> On Sat, Jan 28, 2012 at 05:30, Tom Lane wrote:
>> Thom Brown writes:
>>> I'm using latest git master (latest entry
>>> 0816fad6eebddb8f1f0e21635e46625815d690b9) and I'm getting an error
>>> when trying to create a large data set with pgbenc
On Sat, Jan 28, 2012 at 05:30, Tom Lane wrote:
> Thom Brown writes:
>> I'm using latest git master (latest entry
>> 0816fad6eebddb8f1f0e21635e46625815d690b9) and I'm getting an error
>> when trying to create a large data set with pgbench:
>
>> LOG: could not stat file "base/pgsql_tmp/pgsql_tmp80
34 matches
Mail list logo
